[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.148 / U:1.412 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site