Re: NFS client latencies

[Ingo Molnar <mingo@elte.hu>]

* Lee Revell <rlrevell@joe-job.com> wrote:

> > Is a bunch of gobbledygook.  Hows about you interpret it for us?
> 
> Sorry.  When I summarized them before, Ingo just asked for the full 
> verbose trace.

please send non-verbose traces if possible. The verbose traces are 
useful when it's not clear which portion of a really large function is 
the call site - but they are also alot harder to read.  Verbose traces 
are basically just a debugging mechanism for me, not meant for public 
consumption.

i can add back the instruction-'offset' to the non-verbose trace, that 
will make even the ext3 traces easily interpretable in the non-verbose 
format.

> The 7 ms are spent in this loop:
> 
>  radix_tree_tag_clear+0xe/0xd0 <c01e040e> (nfs_scan_lock_dirty+0xb2/0xf0 <c01c3a22>)
>  radix_tree_tag_clear+0xe/0xd0 <c01e040e> (nfs_scan_lock_dirty+0xb2/0xf0 <c01c3a22>)
>  radix_tree_tag_clear+0xe/0xd0 <c01e040e> (nfs_scan_lock_dirty+0xb2/0xf0 <c01c3a22>)
>  radix_tree_tag_clear+0xe/0xd0 <c01e040e> (nfs_scan_lock_dirty+0xb2/0xf0 <c01c3a22>)
>  radix_tree_tag_clear+0xe/0xd0 <c01e040e> (nfs_scan_lock_dirty+0xb2/0xf0 <c01c3a22>)

the trace shows thousands of pages getting submitted - each of the line 
above is at least one new page. The loop is not preemptible right now 
but that should be easy to bound. Note that your earlier traces showed 
the list sorting overhead for a _single page_. So it's a huge difference 
and a huge step forward.

	Ingo