On 12/05/11 10:47, Lachlan Mulcahy wrote:
> zfs`lzjb_decompress 10 0.0%
> unix`page_nextn 31 0.0%
> genunix`fsflush_do_pages 37 0.0%
> zfs`dbuf_free_range 183 0.1%
> genunix`list_next 5822 3.7%
> unix`mach_cpu_idle 150261 96.1%
your best bet in a situation like this -- where there's a lot of cpu time
spent in a generic routine -- is to use an alternate profiling method that
shows complete stack traces rather than just the top function on the stack.
often the names of functions two or three or four deep in the stack will point
at what's really responsible.
something as simple as:
dtrace -n 'profile-1001 { @[stack()] = count(); }'
(let it run for a bit then interrupt it).
should show who's calling list_next() so much.
- Bill
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
