Re: [PATCH] Instrumenting high latency

[William Lee Irwin III]

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