Message-ID: <421FA61B.9050705@us.ibm.com>
Date: Fri, 25 Feb 2005 14:26:35 -0800
From: Darren Hart <dvhltc@us.ibm.com>
User-Agent: Debian Thunderbird 1.0 (X11/20050116)
MIME-Version: 1.0
To: Chris Wright <chrisw@osdl.org>
CC: hugh@veritas.com, akpm@osdl.org, andrea@suse.de,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] allow vma merging with mlock et. al.
References: <421E74B5.3040701@us.ibm.com> <20050225171122.GE28536@shell0.pdx.osdl.net> <20050225220543.GC15867@shell0.pdx.osdl.net>
In-Reply-To: <20050225220543.GC15867@shell0.pdx.osdl.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1314
Lines: 34

Chris Wright wrote:
> * Chris Wright (chrisw@osdl.org) wrote:
> 
>>* Darren Hart (dvhltc@us.ibm.com) wrote:
>>
>>>The were a couple long standing (since at least 2.4.21) superfluous 
>>>variables and two unnecessary assignments in do_mlock().  The intent of 
>>>the resulting code is also more obvious.
>>>
>>>Tested on a 4 way x86 box running a simple mlock test program.  No 
>>>problems detected.
>>
>>Did you test with multiple page ranges, and locking subsets of vmas?
>>Seems that splitting could cause a problem since you now sample vm_end
>>before and after fixup, where the vma could be changed in the middle.
> 
> 
> Actually I think it winds up being fine since we don't do merging with
> mlock.  But why not?  Patch below remedies that.

We don't merge, but we do split if necessary, so the temp variables are 
still needed.  As I understand it, the reason we don't merge is because 
it is expected that a task will lock and unlock the same memory range 
more than once and we don't want to waste our time merging and splitting 
the VMAs.

Thanks,

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