[lkml]   [2001]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: The cause of the "VM" performance problem with 2.4.X
> > 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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:58    [W:0.662 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site