Re: RT patch acceptance

[Ingo Molnar <mingo@elte.hu>]

* Andi Kleen <ak@muc.de> wrote:

> On Fri, May 27, 2005 at 02:48:37PM +0200, Ingo Molnar wrote:
> > * Andi Kleen <ak@muc.de> wrote:
> > 
> > > [...] Even normal kernels must have reasonably good latency, as long 
> > > as it doesnt cost unnecessary performance.
> > 
> > they do get reasonably good latency (within the hard constraints of the 
> > possibilities of a given preemption model), due to the cross-effects 
> > between the various preemption models, that i explained in detail in 
> > earlier mails. Something that directly improves latencies on 
> > CONFIG_PREEMPT improves the 'subsystem-use latencies' on PREEMPT_RT.  
> 
> I was more thinking of improvements for !PREEMPT.

how would you do that, if even a first step (PREEMPT_VOLUNTARY) was 
opposed by some as possibly hurting throughput? I'm really curious, what 
would you do to improve PREEMPT_NONE's latencies?

> > Also there's the positive interaction between scalability and latencies 
> > as well.
>
> That sound more like bugs that should just be fixed in the main kernel 
> by more scheduling. Can you give details and examples?

what i meant is a pretty common-sense thing: the more independent the
locks are, the more shortlived locking is, the less latencies there are.
The reverse is true too: most of the latency-breakers move code out from
under locks - which obviously improves scalability too. So if you are 
working on scalability you'll indirectly improve latencies - and if you 
are working on reducing latencies, you often improve scalability.

> > but it's certainly not for free. Just like there's no zero-cost
> > virtualization, or there's no zero-cost nanokernel approach either,
> > there's no zero-cost single-kernel-image deterministic system either.
> > 
> > and the argument about binary kernels - that's a choice up to vendors
> 
> It is not only binary distribution kernels. I always use my own self
> compiled kernels, but I certainly would not want a special kernel just
> to do something normal that requires good latency (like sound use).

for good sound you'll at least need PREEMPT_VOLUNTARY. You'll need 
CONFIG_PREEMPT for certain workloads or pro-audio use.

> > and users. Right now PREEMPT_NONE is dominant, so do you argue that
> > CONFIG_PREEMPT should be removed? It's certainly not zero-cost even on
> > the source code, witness all the preempt_disable()/preempt_enable() or
> > get_cpu()/put_cpu() uses.
> 
> Actually yes I would. AFAIK CONFIG_PREEMPT never improved latency 
> considerably (from the numbers Ive seen), but it had extreme cost in 
> the code base (like all this get/put cpu mess and the impact on RCU 
> was also not pretty)
>
> So it never seemed very useful to me. May be it would have been better 
> if it had been made UP only, that would at least have avoided a lot of 
> issues.
> 
> But at least CONFIG_PREEMPT is still reasonably cheap, so it is not as 
> intrusive as some of the stuff proposed.

the impact of PREEMPT on the codebase has a positive effect as well: it 
forces us to document SMP data structure dependencies better. Under 
PREEMPT_NONE it would have been way too easy to get into the kind of 
undocumented interdependent data structure business that we so well know 
from the big kernel lock days. get_cpu()/put_cpu() precisely marks the 
critical section where we use a given per-CPU data structure.

	Ingo