lkml.org 
[lkml]   [2012]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v2] Support volatile range for anon vma
On 12/04/2012 08:18 PM, Minchan Kim wrote:
> On Tue, Dec 04, 2012 at 11:13:40AM -0800, John Stultz wrote:
>> I don't think the problem is when vmas being marked VM_VOLATILE are
>> being merged, its that when we mark the vma as *non-volatile*, and
>> remove the VM_VOLATILE flag we merge the non-volatile vmas with
>> neighboring vmas. So preserving the purged flag during that merge is
>> important. Again, the example I used to trigger this was an
>> alternating pattern of volatile and non volatile vmas, then marking
>> the entire range non-volatile (though sometimes in two overlapping
>> passes).
> Understood. Thanks.
> Below patch solves your problems? It's simple than yours.

Yea, this is nicer then my fix.
Although I still need the purged handling in the vma merge code for me
to see the behavior I expect in my tests.

I've integrated your patch and repushed my queue here:
http://git.linaro.org/gitweb?p=people/jstultz/android-dev.git;a=shortlog;h=refs/heads/dev/minchan-anonvol

git://git.linaro.org/people/jstultz/android-dev.git dev/minchan-anonvol

> Anyway, both yours and mine are not right fix.
> As I mentioned, locking scheme is broken.
> We need anon_vma_lock to handle purged and we should consider fork
> case, too.
Hrm. I'm sure you're right, as I've not yet fully grasped all the
locking rules here. Could you clarify how it is broken? And why is the
anon_vma_lock needed to manage the purged state that is part of the vma
itself?

thanks
-john



\
 
 \ /
  Last update: 2012-12-08 02:01    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog