Messages in this thread | | | Date | Tue, 15 Jun 2010 14:28:22 +0400 | From | Evgeniy Polyakov <> | Subject | Re: [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
| |