linux-kernel - Re: [PATCH 0/12] Avoid overflowing of stack during page reclaim V2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Jun 2010 09:08:33 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, Dave Chinner <david@...morbit.com>,
	Chris Mason <chris.mason@...cle.com>,
	Nick Piggin <npiggin@...e.de>, Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/12] Avoid overflowing of stack during page reclaim V2

On Mon, 14 Jun 2010 12:17:41 +0100
Mel Gorman <mel@....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...


> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/