Re: [PATCH V8 1/2] mm: memcg softlimit reclaim rework

[Ying Han <yinghan@google.com>]

On Mon, Aug 20, 2012 at 6:19 AM, Kamezawa Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> (2012/08/18 7:03), Ying Han wrote:
>>
>> On Mon, Aug 6, 2012 at 6:33 AM, Michal Hocko <mhocko@suse.cz> wrote:
>>>
>>> On Fri 03-08-12 09:34:11, Ying Han wrote:
>>>>
>>>> On Fri, Aug 3, 2012 at 9:16 AM, Rik van Riel <riel@redhat.com> wrote:
>>>>>
>>>>> On 08/03/2012 11:22 AM, Michal Hocko wrote:
>>>>>>
>>>>>>
>>>>>> On Thu 02-08-12 14:24:18, Ying Han wrote:
>>>>>>
>>>>>> I am thinking that we could add a constant for the priority
>>>>>> limit. Something like
>>>>>> #define MEMCG_LOW_SOFTLIMIT_PRIORITY    DEF_PRIORITY
>>>>>>
>>>>>> Although it doesn't seem necessary at the moment, because there is
>>>>>> just
>>>>>> one location where it matters but it could help in the future.
>>>>>> What do you think?
>>>>>
>>>>>
>>>>>
>>>>> I am working on changing the code to find the "highest priority"
>>>>> LRU and reclaim from that list first.  That will obviate the need
>>>>> for such a change. However, the other cleanups and simplifications
>>>>> made by Ying's patch are good to have...
>>>>
>>>>
>>>> So what you guys think to take from here. I can make the change as
>>>> Michal suggested if that would be something helpful future changes.
>>>> However, I wonder whether or not it is necessary.
>>>
>>>
>>> I am afraid we will not move forward without a proper implementation of
>>> the "nobody under soft limit" case. Maybe Rik's idea would just work out
>>> but this patch on it's own could regress so taking it separately is no
>>> go IMO. I like how it reduces the code size but we are not "there" yet...
>>>
>>
>> Sorry for getting back to the thread late. Being distracted to
>> something else which of course happens all the time.
>>
>> Before me jumping into actions of any changes, let me clarify the
>> problem I am facing:
>>
>> All the concerns are related to the configuration where none of the
>> memcg is eligible for reclaim ( usage < softlimit ) under global
>> pressure.   The current code works like the following:
>>
>> 1. walk the memcg tree and for each checks the softlimit
>> 2. if none of the memcg is being reclaimed, then set the ignore_softlimit
>> 3. restart the walk and this round forget about the softlimit
>>
>> There are two problems I heard here:
>> 1. doing a full walk on step 1 would cause potential scalability issue.
>>
>
> Simply thinking, I think maintaining & updating the whole softlimit
> information
> periodically is a way to avoid double-scan. memcg has a percpu event-counter
> and
> css-id bitmap will be enough for keeping information. Then, you can find
> over-softlimit memcg by bitmap scanning.
>
>
>
>> 2. root cgroup is a exception where it always eligible for reclaim (
>> softlimit = 0 always). That will cause root to be punished more than
>> necessary.
>>
>
> When use_hierarchy==0 ?
> How about having implicit softlimit value for root, which is automatically
> calculated from total_ram or the number of tasks in root ?

No, we have use_hierarchy set to 1 for root. Also, as part of the
patchset the softlimit of root is set to 0 and  also can not be
modified later. There is a reason behind it mainly because now we
check the softlimit of a memcg hierarchically.

Calculating the softlimit for root sounds an over-kill and not
necessary. It works fine to have softlimit of root to 0 and we just
need to fix the inefficiency in the code where no non-memcg is above
softlimit. In that case, we don't want to over-punish root.

My current version is to not counting root to set ignore_softlimit
flag, so at least the second round of scanning will look at all the
other memcgs. I don't see a major problem of it apart from the
scalability concern addressed on 1.

--Ying

> Thanks,
> -Kame
>
>
>
>
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>