From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wli by holomorphy with local (Exim 3.34 #1 (Debian)) id 175xNp-0003VR-00 for ; Thu, 09 May 2002 16:31:37 -0700 Date: Thu, 9 May 2002 16:31:36 -0700 From: William Lee Irwin III Subject: Re: [RFC] tabulating page->virtual on highmem Message-ID: <20020509233136.GS15756@holomorphy.com> References: <20020508221506.GL15756@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline In-Reply-To: <20020508221506.GL15756@holomorphy.com> Sender: owner-linux-mm@kvack.org Return-Path: To: linux-mm@kvack.org List-ID: On Wed, May 08, 2002 at 03:15:06PM -0700, William Lee Irwin III wrote: > The size of the kmap pool appears to dictate the number of distinct > values of page->virtual. Maintaining an index into the pool would > seem to provide superior space behavior, as the index need not be > of full machine word precision. Furthermore, no auxiliary lookup > would appear to be required as the kmap pool is virtually contiguous > and so the virtual address could be calculated from base virtual > address of the kmap pool and the index into the pool. > For architectures using page->virtual for page_address() calculation > this technique does not apply, and so page->virtual would then need > to be maintained as is, or at least retain enough precision for a full > page frame number. > I don't have my heart set on this but I thought I'd at least throw the > idea out where its desirability (and potential implementations) could > be discussed. Since no one's screamed too loudly I'll push out an implementation of this sometime in the next few days. Cheers, Bill -- 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/