Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Testing 7.0 Beta: FFS still very slow when creating files
Okay maybe I should wait for dtrace to be enabled and working by default.
As I said, I could´t even enter ddb. Otherwise I could have placed a
breakpoint on mutex_enter() to get example stack traces. I wonder,
though, if this really can be related to locking as this test is
basically single-threaded.
Regards,
Stephan
2014-08-22 18:29 GMT+02:00 Taylor R Campbell <riastradh%netbsd.org@localhost>:
> Date: Fri, 22 Aug 2014 17:59:37 +0200
> From: Stephan <stephanwib%googlemail.com@localhost>
>
> Has anybody an idea on this or how to track this down? At the moment,
> I can't even enter ddb using Strg+Alt+Esc keys for some reason. I've
> also seen people playing with dtrace but that doesn't seem to be
> included.
>
> Dtrace may be a good idea. You can use it by
>
> (a) using a kernel built with `options KDTRACE_HOOKS',
> (b) using a userland built with MKDTRACE=yes,
> (c) modload /stand/ARCH/VERSION/solaris.kmod
> modload /stand/ARCH/VERSION/dtrace.kmod
> modload /stand/ARCH/VERSION/fbt.kmod
> modload /stand/ARCH/VERSION/sdt.kmod
> (d) mkdir /dev/dtrace && mknod /dev/dtrace/dtrace c dtrace
>
> (Yes, this is too much work. Someone^TM should turn it all on by
> default for netbsd-7...!)
>
> From the lockstat output it looks like there's a lot of use of
> mntvnode_lock, which suggests this may be related to hannken@'s vnode
> cache changes. Might be worthwhile to sample stack traces of
> vfs_insmntque, with something like
>
> dtrace -n 'fbt::vfs_insmntqueue:entry { @[stack()]++ }'
>
> or perhaps sample stack traces of the mutex_enters of mntvnode_lock.
Home |
Main Index |
Thread Index |
Old Index