On Mon, 28 Feb 2005, Chris Wright wrote:
>
> Successive mlock/munlock calls can leave fragmented vmas because they can
> be split but not merged. Give mlock et. al. full vma merging support.
> While we're at it, move *pprev assignment above first split_vma in
> mprotect_fixup to keep it in step w
* Hugh Dickins ([EMAIL PROTECTED]) wrote:
> On Fri, 25 Feb 2005, Chris Wright wrote:
> >
> > Actually I think it winds up being fine since we don't do merging with
> > mlock. But why not? Patch below remedies that.
>
> > Successive mlock/munlock calls can leave fragmented vmas because they can
On Fri, 25 Feb 2005, Chris Wright wrote:
>
> Actually I think it winds up being fine since we don't do merging with
> mlock. But why not? Patch below remedies that.
I shared Darren's assumption, that mlock merging had been found too
expensive. But Andrea says it's just that nobody asked for it
* Andrea Arcangeli ([EMAIL PROTECTED]) wrote:
> The object of the merge is to save memory, and to reduce the size of the
> rbtree that might payoff during other operations (with a smaller tree,
> lookups will be faster too). If you only measure the time of creating
> and removing a mapping then it
On Fri, Feb 25, 2005 at 03:38:06PM -0800, Chris Wright wrote:
> I don't have a good sampling of applications. The one's I've used are
> temporal like gpg, or they mlockall the whole thing and never look back.
> But I did a quick benchmark since I was curious, a simple loop of a
> million lock/unlo
* Darren Hart ([EMAIL PROTECTED]) wrote:
> 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.
I don't have a good sampling of appl
Chris Wright wrote:
* Chris Wright ([EMAIL PROTECTED]) wrote:
* Darren Hart ([EMAIL PROTECTED]) 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
7 matches
Mail list logo
