lkml.org 
[lkml]   [2012]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -V4 04/10] memcg: Add HugeTLB extension
(2012/03/21 13:48), Aneesh Kumar K.V wrote:

> Glauber Costa <glommer@parallels.com> writes:
>
>> On 03/19/2012 11:00 AM, KAMEZAWA Hiroyuki wrote:
>>> (2012/03/19 15:52), Aneesh Kumar K.V wrote:
>>>
>>>>
>>>>>> +#ifdef CONFIG_MEM_RES_CTLR_HUGETLB
>>>>>> +static bool mem_cgroup_have_hugetlb_usage(struct mem_cgroup *memcg)
>>>>>> +{
>>>>>> + int idx;
>>>>>> + for (idx = 0; idx< hugetlb_max_hstate; idx++) {
>>>>>> + if (memcg->hugepage[idx].usage> 0)
>>>>>> + return 1;
>>>>>> + }
>>>>>> + return 0;
>>>>>> +}
>>>>>
>>>>>
>>>>> Please use res_counter_read_u64() rather than reading the value directly.
>>>>>
>>>>
>>>> The open-coded variant is mostly derived from mem_cgroup_force_empty. I
>>>> have updated the patch to use res_counter_read_u64.
>>>>
>>>
>>> Ah, ok. it's(maybe) my bad. I'll schedule a fix.
>>>
>> Kame,
>>
>> I actually have it ready here. I can submit it if you want.
>>
>> This one has bitten me as well when I was trying to experiment with the
>> res_counter performance...
>
> Do we really need memcg.res.usage to be accurate in that while loop ? If
> we miss a zero update because we encountered a partial update; in the
> next loop we will find it zero right ?
>

At rmdir(), I assume there is no task in memcg. It means res->usage never
increase and no other thread than force_empty will touch res->counter.
So, I think memcg->res.usage > 0 never be wrong and we'll find correct comparison
by continuing the loop.

But recent kmem accounting at el may break the assumption (I'm not fully sure..)
So, I think it will be good to use res_counter_u64(). This part is not important for
performance, anyway.

Thanks,
-Kame





\
 
 \ /
  Last update: 2012-03-21 06:27    [W:0.101 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site