lkml.org 
[lkml]   [2010]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 11/12] vmscan: Write out dirty pages in batch
On Tue, Jun 15, 2010 at 04:36:43PM +1000, Dave Chinner (david@fromorbit.com) 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


\
 
 \ /
  Last update: 2010-06-15 12:49    [W:1.556 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site