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
writing).
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/