lkml.org 
[lkml]   [2010]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/12] Avoid overflowing of stack during page reclaim V2
On Tue, Jun 15, 2010 at 09:08:33AM +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 14 Jun 2010 12:17:41 +0100
> Mel Gorman <mel@csn.ul.ie> wrote:
>
> > SysBench
> > ========
> > traceonly-v2r5 stackreduce-v2r5 nodirect-v2r5
> > 1 11025.01 ( 0.00%) 10249.52 (-7.57%) 10430.57 (-5.70%)
> > 2 3844.63 ( 0.00%) 4988.95 (22.94%) 4038.95 ( 4.81%)
> > 3 3210.23 ( 0.00%) 2918.52 (-9.99%) 3113.38 (-3.11%)
> > 4 1958.91 ( 0.00%) 1987.69 ( 1.45%) 1808.37 (-8.32%)
> > 5 2864.92 ( 0.00%) 3126.13 ( 8.36%) 2355.70 (-21.62%)
> > 6 4831.63 ( 0.00%) 3815.67 (-26.63%) 4164.09 (-16.03%)
> > 7 3788.37 ( 0.00%) 3140.39 (-20.63%) 3471.36 (-9.13%)
> > 8 2293.61 ( 0.00%) 1636.87 (-40.12%) 1754.25 (-30.75%)
> > FTrace Reclaim Statistics
> > traceonly-v2r5 stackreduce-v2r5 nodirect-v2r5
> > Direct reclaims 9843 13398 51651
> > Direct reclaim pages scanned 871367 1008709 3080593
> > Direct reclaim write async I/O 24883 30699 0
> > Direct reclaim write sync I/O 0 0 0
>
> Hmm, page-scan and reclaims jumps up but...
>

It could be accounted for by the fact that the direct reclaimers are
stalled less in direct reclaim. They make more forward progress needing
more pages so end up scanning more as a result.

>
> > User/Sys Time Running Test (seconds) 734.52 712.39 703.9
> > Percentage Time Spent Direct Reclaim 0.00% 0.00% 0.00%
> > Total Elapsed Time (seconds) 9710.02 9589.20 9334.45
> > Percentage Time kswapd Awake 0.06% 0.00% 0.00%
> >
>
> Execution time is reduced. Does this shows removing "I/O noise" by direct
> reclaim makes the system happy? or writeback in direct reclaim give
> us too much costs ?
>

I think it's accounted for by just making more forward progress rather than
IO noise. The throughput results for sysbench are all over the place because
the disk was maxed so I'm shying away from drawing any conclusions on the
IO efficiency.

> It seems I'll have to consider about avoiding direct-reciam in memcg, later.
>
> BTW, I think we'll have to add wait-for-pages-to-be-cleaned trick in
> direct reclaim if we want to avoid too much scanning, later.
>

This happens for lumpy reclaim. I didn't think it was justified for
normal reclaim based on the percentage of dirty pages encountered during
scanning. If the percentage of dirty pages scanned, we'll need to first
figure out why that happened and then if stalling when they are
encountered is the correct thing to do.

>
> Thank you for interesting test.
>

You're welcome.

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab


\
 
 \ /
  Last update: 2010-06-15 13:53    [from the cache]
©2003-2011 Jasper Spaans