[lkml]   [1998]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: elevator algorithm bug in ll_rw_blk.c
In message <>, "Stephen C. Tweedie" wr
> I suspect that in this sort of situation we are being hit by two
> separate known problems:
> 1) We only have a single request queue shared by all block devices.
> 2) Parallel sync()s interfere badly with each other.

Yes, this fits exactly. When the performance goes to pot, there are
multiple processes hung in the 'D' state.

> If you have lots of large writers, then as those writers compete for
> buffer cache space, they will all start synching each other's buffers to
> disk. I've been toying with the idea of just stomping on this problem
> totally by imposing a strict limit on the amount of dirty data we allow
> for any given disk (or maybe per process). If we avoid the buffer-cache
> thrashing threshold, then we can just let bdflush do its normal job of
> writeback and we have a single sync thread which is not interfered with
> by the rest of the system.
> The cost of course is reduced concurrency.
> Any thoughts?

Make the dirty block list a partially ordered list?

i.e. add blocks to the list, preserving ordering from the last X
point, where the X point is set at the end of the list when syncs or
writes are queued.

I don't think I'm explaining that well. The idea is take all the
current dirty blocks on the list, sort them, and write them. Then take
all the blocks added since the last time we took all, sort them and
write them. etc etc.

This should make sure we don't starve blocks, but auto-enlarge the
sorting window as the load increases. (something like nargle for


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.101 / U:1.872 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site