lkml.org 
[lkml]   [2004]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ck] Re: Preempt Threshold Measurements
William Lee Irwin III <wli@holomorphy.com> wrote:
>
> On Mon, Jul 12, 2004 at 10:48:50PM -0400, Gabriel Devenyi wrote:
> > Well I'm not particularly educated in kernel internals yet, here's some
> > reports from the system when its running.
> > 6ms non-preemptible critical section violated 4 ms preempt threshold starting
> > at do_munmap+0xd2/0x140 and ending at do_munmap+0xeb/0x140
> > [<c014007b>] do_munmap+0xeb/0x140
> > [<c01163b0>] dec_preempt_count+0x110/0x120
> > [<c014007b>] do_munmap+0xeb/0x140
> > [<c014010f>] sys_munmap+0x3f/0x60
> > [<c0103ee1>] sysenter_past_esp+0x52/0x71
>
> Looks like ZAP_BLOCK_SIZE may be too large for you. Lowering that some
> may "help" this. It's probably harmless, but try lowering that to half
> of whatever it is now, or maybe 64*PAGE_SIZE. It may be worthwhile
> to restructure how the preemption points are done in unmap_vmas() so
> we don't end up in some kind of tuning nightmare.

Does that instrumentation patch have the cond_resched_lock() fixups? If
not, this is a false positive.

The current setting of ZAP_BLOCK_SIZE is good for sub-500usec latencies on
a recentish CPU.

-
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.078 / U:0.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site