lkml.org 
[lkml]   [2008]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][2/3] Account and control virtual address space allocations (v2)
[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


\
 
 \ /
  Last update: 2008-03-27 09:43    [W:0.050 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site