Re: [PATCH 0/12] Avoid overflowing of stack during page reclaim V2
From: KAMEZAWA Hiroyuki
Date: Mon Jun 14 2010 - 20:13:21 EST
On Mon, 14 Jun 2010 12:17:41 +0100
Mel Gorman <mel@xxxxxxxxx> 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...
> 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 ?
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.
Thank you for interesting test.
Regards,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/