From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Cameron Davies Date: Thu, 1 Jun 2006 13:21:01 +1000 (EST) Subject: Re: [Patch 0/17] PTI: Explation of Clean Page Table Interface In-Reply-To: <447CFEAA.5070206@yahoo.com.au> Message-ID: References: <447C055A.9070906@sgi.com> <447CFEAA.5070206@yahoo.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Jes Sorensen , linux-mm@kvack.org List-ID: On Wed, 31 May 2006, Nick Piggin wrote: > Paul Cameron Davies wrote: > >> Hi Jes >> >> I concede that I am acutely aware that 3.5% is just too high, but we know >> which abstractions are causing the problems. >> >> We will hope to nail down some of these problems in the next few weeks >> and then feed again. >> >> What level of degradation in peformance in acceptable (if any)? > > > For upstream inclusion? negative degradation, I'd assume: you're adding > significant complexity so there has to be some justification for it... Our long term goal is upstream inclusion. We are planning to release early and release often to get feedback and exposure. We want to bring around the people that don't have a vested interest in cleanly accessing the page tables, and get early input into the direction the interface should take. > And unless it is something pretty significant, I'd almost bet that Linus, > if nobody else, will veto it. Our radix-tree v->p data structure is > fairly clean, performant, etc. It matches the logical->physical radix > tree data structure we use for pagecache as well. Being able to change the page table on a 64 bit machine will be a huge advantage into the future when applications really start to make use of the 64 bit address space. The current trie (multi level page table - MLPT) is not going to perform against more sophisticated data structures in a sparsely occupied 64 bit address space At UNSW we are experimenting with different page tables. We have replaced the MLPT in Linux with a GPT (guarded page table), running on an older kernel. The GPT is essentially an unconstrained radix tree (a specialed MLPT). GPTs are naturally suited to page table sharing and the seamless implementation of Superpages. (please refer to Liedtke's paper, Address Space Sparsity and fine granularity, ACM Operating Systems Review, vol 29, pp87-90, January 1995). We are looking to provide alternate page table options in Linux to enable Linux to continue to boast about its scalability as an operating system. The MLPT is not going to scale from the 32 bit address space to the 64 bit address space. Unfortunately some concession may need to be made by some architectures to support this. > BTW. I reckon your performance problems are due to indirect function > calls. Thanks. This is certainly a large part of the performance problem. The problem is, thus far it is the most efficient solution I have come up with. Cheers Paul -- 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