Re: [RFC][2/3] Account and control virtual address space allocations(v2)

[Pavel Emelyanov]

[snip]

>>>>> +	css_put(&mem->css);
>>>> Why don't you check whether the counter is charged? This is
>>>> bad for two reasons:
>>>> 1. you allow for some growth above the limit (e.g. in expand_stack)
>>> I was doing that earlier and then decided to keep the virtual address space code
>>> in sync with the RLIMIT_AS checking code in the kernel. If you see the flow, it
>>> closely resembles what we do with mm->total_vm and may_expand_vm().
>>> expand_stack() in turn calls acct_stack_growth() which calls may_expand_vm()
>> But this is racy! Look - you do expand_stack on two CPUs and the limit is
>> almost reached - so that there's room for a single expansion. In this case 
>> may_expand_vm will return true for both, since it only checks the limit, 
>> while the subsequent charge will fail on one of them, since it actually 
>> tries to raise the usage...
>>
> 
> Hmm... yes, possibly. Thanks for pointing this out. For a single mm_struct, the
> check is done under mmap_sem(), so it's OK for processes. I suspect, I'll have

Sure, but this controller should work with arbitrary group of processes ;)

> to go back to what I had earlier. I don't want to add a mutex to mem_cgroup,
> that will hurt parallelism badly.

My opinion is that we should always perform a pure charge without any
pre-checks, etc.

Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/