WAPBL on multicore, 1 (ONE!) process...

["Martin S. Weber" <Ephaeton%gmx.net@localhost>]

I've been loosely following the bug report about how wapbl negatively
impacts performance on a parallel build and somesuch. I got hands on
a new machine at work (dmesg here: [1]), and decided to give -o log a
try after it's running just nicely on my home laptop (which I "have"
to crash on a regular base also where -o log greatly helps).
I experienced the painful slowness and impact of 'make extract' on
one package effectively stalling the whole system (like, have a
cat /etc/mk.conf sit there waiting several seconds until it spews
out something), and trickling along at an unacceptable rate.

Now I've read about WAPBL_DEBUG_SERIALIZE and how it claims to help
with this effect. "Claims" is the right word to use here. I'm quoting
the man page here:

" The option

        options WAPBL_DEBUG_SERIALIZE

forces the serialization of all IO.  This is currently be used to help
alleviate a performance issue seen on multi-core machines, where multiple
simultaneous extractions of tar-files can cause degenerate performance. "

Well, what I've seen I wouldn't call the effect 'degenerate performance'
as 'performance' shouldn't be anywhere near a sentence describing reality.
Secondly, the option doesn't help at all. Before that, I would see 1.2M
of disk throughput (as displayed by xosview). After that, I would see 1.2M
of disk throughput. And now to the best part: I've tested that with moving
over a directory tree from one -o log mounted partition to another -o log
mounted partition on the same disk. It'll push over data with like 60, 70M/s
until it comes to adjusting metadata, then it'll drop to 1.2M. I sat there
hours, not daring to interrupt execution. Again, this is a -single- mv,
nothing else happening on the machine at all. No "multiple simultaneous"
anything. Nope, Sir. Just a plain mv of a directory hierarchy.

Afterwards, I continued with some parallel makes in pkgsrc (extract in
openoffice while also building gimp). Still, 1.2M ... gimp compiles so slowly
I can read the whole command line of each gcc invocation like twice before
the next object file gets compiled. So I interrupted the two, remounted the
partition pkgsrc is on without -o log .. et voila! Performance went up by
a factor of *thirty*. Yup, you're reading right... Also the cpu got some
usage again, as compared to sitting there at 0% all the time.

I dunno .. maybe the option WAPBL_DEBUG_SERIALIZE can be removed again,
for - at least for me - it doesn't change anything about the performance.
It sucks before, it sucks afterwards. I'm surprised to see my home laptop
(a cure duo in contrast to the quadcore at work) having a nice performance
with wapbl...

I'm not asking if anybody else has seen this because I know they have;
I'm just wondering whether wapbl will go into 5.0 in that state.

-Martin

[1]: http://ayaken.net/dmesg.boot.uranos