On Tue, 2006-07-25 at 13:45, Rainer Orth wrote:
> At other times, the kernel time can be even as high as 80%. Unfortunately,
> I've not been able to investigate how usec_delay is called since there's no
> fbt provider for that function (nor for the alternative entry point
> drv_usecwait found in uts/sun4[uv]/cpu/common_asm.s), so I'm a bit stuck
> how to further investigate this. I suspect that the dad(7D) driver is the
> culprit, but it is only included in the closed tarball. In the EDU S9
> sources, I find that dcd_flush_cache() calls drv_usecwait(1000000), which
> might be the cause of this.
In the future, you can try:
# lockstat -s 10 -I sleep 10
which aggregates on the full stack trace, not just the caller, during
profiling interrupts. (-s 10 sets the stack depth; tweak up or down to
taste).
> How should I proceed to further investigate this, and can this be fixed
> somehow? This way, the machine is almost unusable as a build machine.
you've rediscovered
6421427 netra x1 slagged by NFS over ZFS leading to long spins in the
ATA driver code
I've updated the bug to indicate that this wass seen on the Sun Blade
1500 as well.
- Bill
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
