lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] sched: fix scheduling latencies for !PREEMPT kernels
    Ingo Molnar wrote:
    > * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    >
    >
    >>No, but I mean putting them right down into fastpaths like the vmscan
    >>one, for example.
    >
    >
    > it is a very simple no-parameters call to a function that reads a
    > likely-cached word and returns. The cost is in the 2-3 cycles range - a
    > _single_ cachemiss can be 10-100 times more expensive, and cachemisses
    > happen very frequently in every iteration of the VM _scanning_ path
    > since it (naturally and inevitably) deals with lots of sparsely
    > scattered data structures that havent been referenced for quite some
    > time.
    >

    OK, this one thing isn't going to be noticable. But why you really
    must have the check for every page, and not in the logical place
    where we batch them up? You're obviously aiming for the lowest
    latencies possible *without* CONFIG_PREEMPT.

    But I'm thinking, why add overhead for people who don't care about
    sub-ms latency (ie. most of us)? And at the same time, why would
    anyone in a latency critical environment not enable preempt?


    > The function (cond_resched()) triggers scheduling only very rarely, you
    > should not be worried about that aspect either.
    >

    No, I'm not worried about that.

    >
    >>And if I remember correctly, you resorted to putting them into
    >>might_sleep as well (but I haven't read the code for a while, maybe
    >>you're now getting decent results without doing that).
    >
    >
    > i'm not arguing that now at all, that preemption model clearly has to be
    > an optional thing - at least initially.
    >

    OK.

    Alternatively, I'd say tell everyone who wants really low latency to
    enable CONFIG_PREEMPT, which automatically gives the minimum possible
    preempt latency, delimited (and defined) by critical sections, instead
    of the more ad-hoc "sprinkling" ;)
    -
    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-03-22 14:06    [W:0.021 / U:1.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site