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

[Nikita Danilov <nikita@clusterfs.com>]

Ananiev, Leonid I writes:
 > Nikita Danilov writes:
 > > You are inhumane. :-)
 > OK. A lame argument was a joke.
 > 
 > > No. User thread will not write _all_ dirty pages (if it does---it's a
 > > bug in the current code and should be fixed):
 > 
 > Some bugs are fixed by the patch.
 > Current kernel generates pdflush thread unlimitedly. It was patched up
 > by introducing MAX_PDFLUSH_THREADS=8. Why just 8? Now

Sorry, I don't understand. pdflush.c appeared in 2.5.8 and

#define MAX_PDFLUSH_THREADS    8

was here from the very beginning: http://www.kernelhq.cc/browse-view.py?fv_nr=107897

 > MAX_PDFLUSH_THREADS still present. But it could be removed.
 > Unlimited thread generation is fixed in proposed patch.
 > 
 > Now we are discussing other wonderful constant write_chunk=48. Why 48?

This is explained in comment just above sync_writeback_pages()
definition. Basically, ratelimit_pages pages might be dirtied between
calls to balance_dirty_pages(), and the latter tries to write out *more*
pages to keep number of dirty pages under control: negative feedback
control loop, of sorts.

 > The patch deletes this magic constant using:
 > -			.nr_to_write	= write_chunk,
 > It was needed in user thread only.
 > 
 > If user thread A writes 1 byte into disk it has to write not all but 48
 > dirty pages. User main work is paused. User thread B continues
 > generating of dirty pages. Thread B is main generator of dirty pages.
 > Thread A found was able to write-out 47 pages only because user B locks
 > inodes. That is why user A forced to wait 0.1 sec and than repeat
 > compulsory community works. User thread lunch wide inodes scanning and
 > list creating but interrupted after 48 pages. It is inefficient method. 

It may so happen, right, but in the long term most of writeback will be
performed by thread B, because, being heavy writer, it will enter
balance_dirty_pages() more often than A.

If you want to get rid of write latencies, you need better accounting,
to know what pages were dirtied by the current thread (or at least their
number), so that synchronous writeback can be fairer.

[...]

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