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]
Message-ID: <20140731123026.GE13561@dhcp22.suse.cz>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ