> > 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:59 EST