Re: serious performance regression in .41

[christos%astron.com@localhost (Christos Zoulas)]

In article <DFC486AF-CA51-4EC2-B132-CD5E06B039DF%eis.cs.tu-bs.de@localhost>,
J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:
>
>Ok, so I tried a kernel with DEBUG+LOCKDEBUG and get the same problems
>you describe:  every 10 to 20 seconds I get hickups of 1 to 2 seconds.
>
>Christos, just to make it clear:  Do you have these problems when
>running a GENERIC or better GENERIC -DIAGNOSTICS kernel?

The hiccups are much less severe, but there are still performance
issues. The machine is a lot slower building than it used to be.
I can try to get precise numbers over the weekend if you want.

BTW, I tried your patch and the sync stats are a lot better
now, but I still get the 1+ second hiccups. I don't know what part
of the code is causing them yet.

I still feel that for low power machines the filtering iterator is
a much better answer, since it avoids a lot of extra work. Why
lock and unlock the mntvnode lock and vget() something you are not
going to use. At least add the ability via flags to skip the
uninteresting vnodes in the iterator.

Finally, before the changes I could run a LOCKDEBUG kernel in
production.  With the vnode iterator, this is now impossible. This
is a serious regression in itself, so even if the performance issues
are resolved in a non-debug kernel, I still consider the change
problematic.

christos