Date: Mon, 8 Mar 2004 10:36:11 -0600
From: Andy Isaacson <adi@hexapodia.org>
To: Arjan van de Ven <arjanv@redhat.com>
Cc: Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
Subject: Re: Some highmem pages still in use after shrink_all_memory()?
Message-ID: <20040308163611.GA8219@hexapodia.org>
References: <20040307144921.GA189@elf.ucw.cz> <20040307164052.0c8a212b.akpm@osdl.org> <20040308063639.GA20793@hexapodia.org> <1078738772.4678.5.camel@laptop.fenrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1078738772.4678.5.camel@laptop.fenrus.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1161
Lines: 24

On Mon, Mar 08, 2004 at 10:39:32AM +0100, Arjan van de Ven wrote:
> > Note that there are some applications for which it is a *bug* if an
> > mlocked page gets written out to magnetic media.  (gpg, for example.)
> 
> mlock() does not guarantee things not hitting magnetic media, just as
> mlock() doesn't guarantee that the physical address of a page doesn't
> change. mlock guarantees that you won't get hard pagefaults and that you
> have guaranteed memory for the task at hand (eg for realtime apps and
> oom-critical stuff)

Well, that's fine -- you can certainly define mlock to have whatever
semantics you want.  But the semantics that gpg depends on are
reasonable, and if mlock is changed to have other semantics, there
should be some way for apps to get the behavior that used to be
implemented by mlock (and *documented* in the mlock man page).

It's a pity that mlock doesn't take a flags argument.

-andy
-
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/