RE: The cause of the "VM" performance problem with 2.4.X

[Van Maren, Kevin]

> > Yes, it helps quite a bit.  Still not as good as I'd like: I don't
> > dare try lots of disks yet :-(
> 
> Great, thanks.  Aside from the lock contention and stuff, how was the
> actual disk throughput affected?  You said that the stock kernel
> basically stops doing anything, yes?

It got really bad.  It would make "progress", but slower than I
can encode the bits on the platter with a hand magnet ;-)
Now, it's only "pretty bad".

> > Looks like blkdev_put() holds kernel_flag for way too long.
> 
> It calls fsync_dev().

Right.  Which ends up calling our friend, write_unlocked_buffers(),
which does locking, but it also holds the kernel lock the entire time.

> There are two n^2 loops in buffer.c.  There's one on the 
> sync_buffers()
> path, which we fixed yesterday.  But there's also a potential 
> O(2n) path
> in balance_dirty().  So if we're calling mark_buffer_dirty() a lot,
> this becomes quadratic.  For this to bite us the BUF_DIRTY list would
> have to be "almost full" of buffers for another device.  There's also
> some weird stuff in sync_buffers() - not sure what it's trying to do.
> I'll take that up with the boss when he gets back from the polar bear
> hunt or whatever it is they do over there.
> 
> Here's a different patch which addresses the balance_dirty() thing
> as well..

It looks like the same patch as yesterday.  Did you attach the wrong
patch?  In any event, it doesn't look like it helps balance_dirty()
at all because the location is not retained across multiple calls
to write_some_buffers().

Kevin Van Maren