Re: [PATCH] Speed up the cdrw packet writing driver

[Andrew Morton]

Peter Osterlund <petero2@xxxxxxxxx> wrote:
>
> > So it basically spins around all the queues keeping them full in a
>  > non-blocking manner.
>  > 
>  > There _are_ times when pdflush will accidentally block.  Say, doing a
>  > metadata read.  In that case other pdflush instances will keep other queues
>  > busy.
>  > 
>  > I tested it up to 12 disks.  Works OK.
> 
>  OK, this should make sure that dirty data is flushed as fast as the
>  disks can handle, but is there anything that makes sure there will be
>  enough dirty data to flush for each disk?
> 
>  Assume there are two processes writing one file each to two different
>  block devices. To be able to dirty more data a process will have to
>  allocate a page, and a page becomes available whenever one of the
>  disks finishes an I/O operation. If both processes have a 50/50 chance
>  to get the freed page, they will dirty data equally fast once steady
>  state has been reached, even if the block devices have very different
>  write bandwidths.

hm.

Page allocation is fairly decoupled from the dirty memory thresholds.  The
process which wants to write to the fast disk will skirt around the pages
which are dirty against the slow disk and will reclaim clean pagecache
instead.  So the writer to the fast disk _should_ be able to allocate pages
sufficiently quickly.

The balance_dirty_pages() logic doesn't care (or know) about whether the
pages are dirty against a slow device of a fast one - it just keeps the
queues full while clamping the amount of dirty memory.  I do think that
it's possible for the writer to the fast device to get blocked in
balance_dirty_pages() due to there being lots of dirty pages against a slow
device.

Or not - the fact that the fast device retires writes more quickly will
cause waiters in balance_dirty_pages() to unblock promptly.

Or not not - we'll probably get into the situation where almost all of the
dirty pages are dirty against the slower device.

hm.  It needs some verification testing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/