linux-kernel - Re: [PATCH] memcg: implement low limits

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <38951361977052@webcorp2g.yandex-team.ru>
Date:	Wed, 27 Feb 2013 18:57:32 +0400
From:	Roman Gushchin <klamm@...dex-team.ru>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Johannes Weiner-Arquette <hannes@...xchg.org>,
	"bsingharora@...il.com" <bsingharora@...il.com>,
	"kamezawa.hiroyu@...fujitsu.com" <kamezawa.hiroyu@...fujitsu.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"kosaki.motohiro@...fujitsu.com" <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>,
	"mel@....ul.ie" <mel@....ul.ie>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Ying Han <yinghan@...gle.com>
Subject: Re: [PATCH] memcg: implement low limits

Please find my comments below.

> More comments on the code bellow.
>
> [...]
>
>>  diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>>  index 53b8201..d8e6ee6 100644
>>  --- a/mm/memcontrol.c
>>  +++ b/mm/memcontrol.c
>>  @@ -1743,6 +1743,53 @@ static void mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask,
>>                            NULL, "Memory cgroup out of memory");
>>   }
>>
>>  +/*
>>  + * If a cgroup is under low limit or enough close to it,
>>  + * decrease speed of page scanning.
>>  + *
>>  + * mem_cgroup_low_limit_scale() returns a number
>>  + * from range [0, DEF_PRIORITY - 2], which is used
>>  + * in the reclaim code as a scanning priority modifier.
>>  + *
>>  + * If the low limit is not set, it returns 0;
>>  + *
>>  + * usage - low_limit > usage / 8  => 0
>>  + * usage - low_limit > usage / 16 => 1
>>  + * usage - low_limit > usage / 32 => 2
>>  + * ...
>>  + * usage - low_limit > usage / (2 ^ DEF_PRIORITY - 3) => DEF_PRIORITY - 3
>>  + * usage < low_limit => DEF_PRIORITY - 2
>
> Could you clarify why you have used this calculation. The comment
> exlaims _what_ is done but not _why_ it is done.
>
> It is also strange (and unexplained) that the low limit will work
> differently depending on the memcg memory usage - bigger groups have a
> bigger chance to be reclaimed even if they are under the limit.

The idea is to decrease scanning speed smoothly.
It's hard to explain why I used exact these numbers. It' like why DEF_PRIORITY is 12?
Just because it works :). Of course, these numbers are an object for discussion/change.

There is a picture in attachment that illustrates how low limits work:
red line - memory usage of cgroup with low_limit set to 1Gb,
blue line - memory usage of another cgroup, where I ran cat <large file> > /dev/null.

>>  + *
>>  + */
>>  +unsigned int mem_cgroup_low_limit_scale(struct lruvec *lruvec)
>>  +{
>>  + struct mem_cgroup_per_zone *mz;
>>  + struct mem_cgroup *memcg;
>>  + unsigned long long low_limit;
>>  + unsigned long long usage;
>>  + unsigned int i;
>>  +
>>  + mz = container_of(lruvec, struct mem_cgroup_per_zone, lruvec);
>>  + memcg = mz->memcg;
>>  + if (!memcg)
>>  + return 0;
>>  +
>>  + low_limit = res_counter_read_u64(&memcg->res, RES_LOW_LIMIT);
>>  + if (!low_limit)
>>  + return 0;
>>  +
>>  + usage = res_counter_read_u64(&memcg->res, RES_USAGE);
>>  +
>>  + if (usage < low_limit)
>>  + return DEF_PRIORITY - 2;
>>  +
>>  + for (i = 0; i < DEF_PRIORITY - 2; i++)
>>  + if (usage - low_limit > (usage >> (i + 3)))
>>  + break;
>
> why this doesn't depend in the current reclaim priority?

How do you want to use reclaim priority here?

I don't like an idea to start ignoring low limit on some priorities.

In my implementation low_limit_scale just "increases" scanning priority, 
but no more than for 10 (DEF_PRIORITY - 2). So, if priority is 0-2, 
the reclaim works as if the priority were 10-12, that means "normal" slow reclaim.

>
>>  +
>>  + return i;
>>  +}
>>  +
>>   static unsigned long mem_cgroup_reclaim(struct mem_cgroup *memcg,
>>                                           gfp_t gfp_mask,
>>                                           unsigned long flags)
>
> [...]
>
>>  diff --git a/mm/vmscan.c b/mm/vmscan.c
>>  index 88c5fed..9c1c702 100644
>>  --- a/mm/vmscan.c
>>  +++ b/mm/vmscan.c
>>  @@ -1660,6 +1660,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>>           bool force_scan = false;
>>           unsigned long ap, fp;
>>           enum lru_list lru;
>>  + unsigned int low_limit_scale = 0;
>>
>>           /*
>>            * If the zone or memcg is small, nr[l] can be 0.  This
>>  @@ -1779,6 +1780,9 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>>           fraction[1] = fp;
>>           denominator = ap + fp + 1;
>>   out:
>>  + if (global_reclaim(sc))
>>  + low_limit_scale = mem_cgroup_low_limit_scale(lruvec);
>
> What if the group is reclaimed as a result from parent hitting its
> limit?

For now, low limits will work only for global reclaim. Enabling them for target reclaim will require some additional checks.
I plan to do this as a separate change.

Thank you for your comments!

--
Regards,
Roman

Download attachment "low_limit_memcg.gif" of type "image/gif" (11206 bytes)