Re: [PATCH 11/12] vmscan: Write out dirty pages in batch

[Evgeniy Polyakov]

On Tue, Jun 15, 2010 at 04:36:43PM +1000, Dave Chinner (david@xxxxxxxxxxxxx) wrote:
> > Nope.  Large-number-of-small-files is a pretty common case.  If the fs
> > doesn't handle that well (ie: by placing them nearby on disk), it's
> > borked.
> 
> Filesystems already handle this case just fine as we see it from
> writeback all the time. Untarring a kernel is a good example of
> this...
> 
> I suggested sorting all the IO to be issued into per-mapping page
> groups because:
> 	a) makes IO issued from reclaim look almost exactly the same
> 	   to the filesytem as if writeback is pushing out the IO.
> 	b) it looks to be a trivial addition to the new code.
> 
> To me that's a no-brainer.

That doesn't coverup large-number-of-small-files pattern, since
untarring subsequently means creating something new, which FS can
optimize. Much more interesting case is when we have dirtied large
number of small files in kind-of random order and submitted them
down to disk.

Per-mapping sorting will not do anything good in this case, even if
files were previously created in a good facion being placed closely and
so on, and only block layer will find a correlation between adjacent
blocks in different files. But with existing queue management it has
quite a small opportunity, and that's what I think Andrew is arguing
about.

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