lkml.org 
[lkml]   [2004]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH]: 4/4 cluster page-out in VM scanner
How well does this integrate with reiser4.;-)

Hans

Nikita Danilov wrote:

>Implement pageout clustering at the VM level.
>
>With this patch VM scanner calls pageout_cluster() instead of
>->writepage(). pageout_cluster() tries to find a group of dirty pages around
>target page, called "pivot" page of the cluster. If group of suitable size is
>found, ->writepages() is called for it, otherwise, page_cluster() falls back
>to ->writepage().
>
>This is supposed to help in work-loads with significant page-out of
>file-system pages from tail of the inactive list (for example, heavy dirtying
>through mmap), because file system usually writes multiple pages more
>efficiently. Should also be advantageous for file-systems doing delayed
>allocation, as in this case they will allocate whole extents at once.
>
>Few points:
>
> - swap-cache pages are not clustered (although they can be, but by
> page->private rather than page->index)
>
> - currently, kswapd clusters all the time, and direct reclaim only when
> device queue is not congested. Probably direct reclaim shouldn't cluster at
> all.
>
> - this patch adds new fields to struct writeback_control and expects
> ->writepages() to interpret them. This is needed, because pageout_cluster()
> calls ->writepages() with pivot page already locked, so that ->writepages()
> is allowed to only trylock other pages in the cluster.
>
> Besides, rather rough plumbing (wbc->pivot_ret field) is added to check
> whether ->writepages() failed to write pivot page for any reason (in latter
> case page_cluster() falls back to ->writepage()).
>
> Only mpage_writepages() was updated to honor these new fields, but
> all in-tree ->writepages() implementations seem to call
> mpage_writepages(). (Except reiser4, of course, for which I'll send a
> (trivial) patch, if necessary).
>
>Numbers that talk:
>
>Averaged number of microseconds it takes to dirty 1GB of
>16-times-larger-than-RAM ext3 file mmaped in 1GB chunks:
>
>without-patch: average: 74188417.156250
> deviation: 10538258.613280
>
> with-patch: average: 69449001.583333
> deviation: 12621756.615280
>
>(Patch is for 2.6.10-rc2)
>
>
>

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.172 / U:0.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site