Re: RT patch acceptance

[Andi Kleen]

On Fri, May 27, 2005 at 02:48:37PM +0200, Ingo Molnar wrote:
> * Andi Kleen <ak@xxxxxx> 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.

> 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? 

> 
> 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).

But that said most Linux users these days use distribution binary kernels,
so we definitely need to take care of them too.

> 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.

-Andi
-
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/