From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="iso-8859-1" From: Daniel Phillips Subject: Re: Why *not* rmap, anyway? Date: Wed, 8 May 2002 01:02:02 +0200 References: <20020507195007.GW15756@holomorphy.com> In-Reply-To: <20020507195007.GW15756@holomorphy.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-mm@kvack.org Return-Path: To: William Lee Irwin III Cc: Rik van Riel , Christian Smith , Joseph A Knapka , "Martin J. Bligh" , linux-mm@kvack.org List-ID: On Tuesday 07 May 2002 21:50, William Lee Irwin III wrote: > On Tuesday 07 May 2002 21:25, William Lee Irwin III wrote: > >> Procedural interfaces to pagetable manipulations are largely what > >> the BSD pmap and SVR4 HAT layers consisted of, no? > > On Tue, May 07, 2002 at 09:47:28PM +0200, Daniel Phillips wrote: > > They factor the interface the wrong way for Linux. You don't want > > to have to search for each (pte *) starting from the top of the > > structure. We need to be able to do bulk processing. The BSD > > interface just doesn't accomodate this. > > Generally the way to achieve this is by anticipating those bulk > operations and providing standardized methods for them. copy_page_range() > and zap_page_range() are already examples of this. For other cases, > it's perhaps a useful layer inversion. What I'm really talking about is how you'd reimplement copy_page_range, zap_page_range, and the other 4-5 primitives that use the 3 nested loops style of traversing the i86-style page table structure. -- Daniel -- 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/