[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0710021304230.26719@blonde.wat.veritas.com>
Date: Tue, 2 Oct 2007 13:19:15 +0100 (BST)
From: Hugh Dickins <hugh@...itas.com>
To: Thayne Harbaugh <thayne@...net>
cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, discuss@...-64.org
Subject: Re: [PATCH] Inconsistent mmap()/mremap() flags
On Tue, 2 Oct 2007, Thayne Harbaugh wrote:
> On Tue, 2007-10-02 at 07:15 +0200, Andi Kleen wrote:
>
> > For mmap you can emulate it by passing a low hint != 0 (e.g. getpagesize())
> > in address but without MAP_FIXED and checking if the result is not beyond
> > your range.
>
> Cool. That's a much better solution for multiple reasons - like you
> mention, MAP_32BIT is only 2GB as well as it's only available on x86_64.
>
> > > > Given for mremap() it is not that easy because there is no "hint" argument
> > > > without MREMAP_FIXED; but unless someone really needs it i would prefer
> > > > to not propagate the hack. If it's really needed it's probably better
> > > > to implement a start search hint for mremap()
I think you can do it already, without us complicating mremap further
with such a start search hint.
First call mmap with a low hint address, the new size you'll be wanting
from the mremap, PROT_NONE, MAP_ANONYMOUS, -1, 0. Then call mremap with
old address, old size, new size, MREMAP_MAYMOVE|MREMAP_FIXED, and new
address as returned by the preparatory mmap.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists