Re: Testing 7.0 Beta: FFS still very slow when creating files

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On 22 Aug 2014, at 18:29, Taylor R Campbell <riastradh%netbsd.org@localhost> 
wrote:

>   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.

This was my first guess too ...

I tried to bisect and got an increase in time from ~15 secs to ~24 secs
between the time stamps '2012-09-18 06:00 UTC' '2012-09-18 09:00 UTC'.

Someone should redo this test as this interval is the import of the
compiler (GCC 4.5.3 -> 4.5.4) and I had to rebuild tools.  I cant
believe this to be a compiler problem.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)

Btw.: my test script is:

#! /bin/sh

mdconfig /dev/md0d 2048000 &
P=${!}
newfs /dev/rmd0a
mount -t ffs -o log /dev/md0a /mnt

(cd /mnt && time sh -c 'seq 1 30000|xargs touch')

umount /mnt
kill ${P}