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

From: Evgeniy Polyakov
Date: Tue Jun 15 2010 - 06:46:14 EST

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

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
Please read the FAQ at