Re: [PATCH] mm: moving dirty pages balancing to pdfludh entirely

[Nikita Danilov <nikita@clusterfs.com>]

Ananiev, Leonid I writes:
 > 
 > Bret Towe writes:
 > > if say some gtk app wants to write to disk it will freeze
 > > until the usb hd is completely done
 > 
 > The proposed patch fixes one real cause of long latency: if a user

Exactly to the contrary: as I explained to you, if you have more devices
than pdflush threads, your patch will result in all system doing IO as
slow as slowest devices in the system. In addition, if you have more
than MAX_PDFLUSH_THREADS processors, some of them cannot be used to
concurrently perform writeback.

 > thread writes 1 byte only to disk it could happen that one has to write
 > all pages dirtied by all threads in the system and wait for it. The

See how wbc.nr_to_write is set up by balance_dirty_pages().

 > patch is tested and gets real benefit on real systems. A common system
 > work is performed in common system thread but not in casual user thread.

To understand the problem I am trying to attract your attention to,
imagine that MAX_PDFLUSH_THREADS equals 1. See what you get? BSD
(pagedaemon everybody waits upon). But Linux is not BSD, thankfully.

 > 
 > The patch does not fix other (bazillion - 1) fictitious freezing causes
 > for imaginary configurations.

Yes, and all the world is VAX (var. "my benchmarking suite"), as they
used to say. :-)

 > 
 > Leonid

Nikita.
-
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/