lkml.org 
[lkml]   [2004]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    > http://www.zip.com.au/~akpm/linux/patches/stuff/rtc-debug.patch
    > and `amlat', from http://www.zip.com.au/~akpm/linux/amlat.tar.gz
    > 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 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:04    [W:0.044 / U:148.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site