lkml.org 
[lkml]   [2005]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Date
    From
    SubjectRe: RT patch acceptance
    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.

    > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-05-27 15:03    [from the cache]
    ©2003-2011 Jasper Spaans