* Lee Revell <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
