Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> > How much would the +4/+8 bytes size increase in
> > buffer_head [on SMP] be frowned upon? 
> 
> It wouldn't be the end of the world.  I'm not clear on what bits of
> the rt-super-low-latency stuff is intended for mainline though?

in the long run, most of it. There are no conceptual barriers so far,
the -RT tree consists of lots of small details and the PREEMPT_RT
framework itself. We are trying to solve (and merge) the small details
first (in upstream), so that PREEMPT_RT itself becomes uncontroversial.

(and it's not really the low latency that matters mainly - more valuable
is the fact that under PREEMPT_RT high latencies are statistically much
more unlikely [you need to do some really intentional and easy to see
things to introduce high latencies], while in the current upstream
kernel, high latencies are often side-effects of pretty normal kernel
coding activities, so low latencies are always a catch-up game that can
never be truly won for sure. So yes, while a 10 usec worst-case latency
under arbitrary Linux workloads [on the right hardware] is indeed sexy,
more important is that things are much more deterministic and hence much
more trustable from a hard-RT POV.)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/