From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 31 May 2007 10:39:14 +0300 Subject: Re: [PATCH] Document Linux Memory Policy Message-ID: <20070531073914.GA32365@minantech.com> References: <1180467234.5067.52.camel@localhost> <1180544104.5850.70.camel@localhost> <20070531061836.GL4715@minantech.com> <20070531064753.GA31143@minantech.com> <20070531071110.GB31143@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: From: glebn@voltaire.com (Gleb Natapov) Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Lee Schermerhorn , linux-mm , Andrew Morton , Andi Kleen List-ID: On Thu, May 31, 2007 at 12:24:06AM -0700, Christoph Lameter wrote: > > > 2. Pagecache pages can be read and written by buffered I/O and > > > via mmap. Should there be different allocation semantics > > > depending on the way you got the page? Obviously no policy > > > for a memory range can be applied to a page allocated via > > > buffered I/O. Later it may be mapped via mmap but then > > > we never use policies if the page is already in memory. > > > If page is already in the pagecache use it. Or return an error if strict > > policy is in use. Or something else :) In my case I make sure that files > > is accessed only through mmap interface. > > On an mmap we cannot really return an error. If your program has just run > then pages may linger in memory. If you run it on another node then the > earlier used pages may be used. I am OK with that behaviour. For already faulted pages there is nothing we can do, so if application really cares it should make sure this doesn't happen (flash file from pagecache before mmap. Is it even possible?). -- Gleb. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org