linux-kernel - Re: [PATCH 2/2] memcg, vmscan: Fix forced scan of anonymous pages

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:	Thu, 31 Jul 2014 14:30:26 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Jerome Marchand <jmarchan@...hat.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 2/2] memcg, vmscan: Fix forced scan of anonymous pages

On Thu 31-07-14 13:49:45, Jerome Marchand wrote:
> When memory cgoups are enabled, the code that decides to force to scan
> anonymous pages in get_scan_count() compares global values (free,
> high_watermark) to a value that is restricted to a memory cgroup
> (file). It make the code over-eager to force anon scan.

OK, I though this was about memcg reclaim according to the subject but
this is in fact global reclaim when there are multiple memcgs present.
Good. You are right that apples are compared to oranges here.

> For instance, it will force anon scan when scanning a memcg that is
> mainly populated by anonymous page, even when there is plenty of file
> pages to get rid of in others memcgs, even when swappiness == 0. It
> breaks user's expectation about swappiness and hurts performance. 
> 
> This patch make sure that forced anon scan only happens when there not
> enough file pages for the all zone, not just in one random memcg.

OK, makes sense to me.

> Signed-off-by: Jerome Marchand <jmarchan@...hat.com>

Although I have never seen this before I can imagine specialized memcgs
running with mostly anon memory so I would even consider it a stable
material.

Acked-by: Michal Hocko <mhocko@...e.cz>

> ---
>  mm/vmscan.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 079918d..3ad2069 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1950,8 +1950,11 @@ static void get_scan_count(struct lruvec *lruvec, int swappiness,
>  	 */
>  	if (global_reclaim(sc)) {
>  		unsigned long free = zone_page_state(zone, NR_FREE_PAGES);
> +		unsigned long zonefile =
> +			zone_page_state(zone, NR_LRU_BASE + LRU_ACTIVE_FILE) +
> +			zone_page_state(zone, NR_LRU_BASE + LRU_INACTIVE_FILE);
>  
> -		if (unlikely(file + free <= high_wmark_pages(zone))) {
> +		if (unlikely(zonefile + free <= high_wmark_pages(zone))) {
>  			scan_balance = SCAN_ANON;
>  			goto out;
>  		}

You could move file and anon further down when we actually use them.
-- 
Michal Hocko
SUSE Labs
--
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/