[lkml]   [2004]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Instrumenting high latency
    On Mon, Jul 12, 2004 at 12:34:18AM -0700, Andrew Morton wrote:
    > OK, small problem. We have code which does, effectively,
    > if (need_resched()) {
    > drop_the_lock();
    > schedule();
    > grab_the_lock();
    > }
    > so if need_resched() stays false then this will hold the lock for a long
    > time and bogus reports are generated:
    > 46ms non-preemptible critical section violated 1 ms preempt threshold starting at exit_mmap+0x26/0x188 and ending at exit_mmap+0x154/0x188
    > To fix that you need to generate high scheduling pressure so that
    > need_resched() is frequently true. On all CPUs. Modify realfeel to pin
    > itself to each CPU, or something like that.

    I suspect it's better to drop in hooks to trap those e.g. in
    cond_resched() and cond_resched_lock().

    On Mon, Jul 12, 2004 at 12:34:18AM -0700, Andrew Morton wrote:
    > This rather decreases the patch's usefulness.
    > The way I normally do this stuff is with
    > and `amlat', from
    > It _might_ be sufficient to redefine need_resched() to just return 1 all
    > the time. If that causes the kernel to livelock then we need to fix that
    > up anyway.

    Less code... not sure how nasty performance the implications are.

    -- wli
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.023 / U:18.020 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site