Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752587AbYCZEQo (ORCPT ); Wed, 26 Mar 2008 00:16:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750881AbYCZEQe (ORCPT ); Wed, 26 Mar 2008 00:16:34 -0400 Received: from g1t0028.austin.hp.com ([15.216.28.35]:9198 "EHLO g1t0028.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750815AbYCZEQd (ORCPT ); Wed, 26 Mar 2008 00:16:33 -0400 Message-ID: <47E9CE00.7060106@fc.hp.com> Date: Tue, 25 Mar 2008 22:16:00 -0600 From: John Marvin User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: linux-ia64@vger.kernel.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: larger default page sizes... References: <20080324.144356.104645106.davem@davemloft.net> <20080325.162244.61337214.davem@davemloft.net> <87tziu5q37.wl%peter@chubb.wattle.id.au> <87lk465mks.wl%peter@chubb.wattle.id.au> In-Reply-To: <87lk465mks.wl%peter@chubb.wattle.id.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2646 Lines: 50 Peter Chubb wrote: > > You end up having to repeat PTEs to fit into Linux's page table > structure *anyway* (unless we can change Linux's page table). But > there's no place in the short format hardware-walked page table (that > reuses the leaf entries in Linux's table) for a page size. And if you > use some of the holes in the format, the hardware walker doesn't > understand it --- so you have to turn off the hardware walker for > *any* regions where there might be a superpage. No, you can set an illegal memory attribute in the pte for any superpage entry, and leave the hardware walker enabled for the base page size. The software tlb miss handler can then install the superpage tlb entry. I posted a working prototype of Shimizu superpages working on ia64 using short format vhpt's to the linux kernel list a while back. > > If you use the long format VHPT, you have a choice: load the > hash table with just the translation that caused the miss, load all > possible hash entries that could have caused the miss for the page, or > preload the hash table when the page is instantiated, with all > possible entries that could hash to the huge page. I don't remember > the details, but I seem to remember all these being bad choices for > one reason or other ... Ian, can you elaborate? When I was doing measurements of long format vs. short format, the two main problems with long format (and why I eventually chose to stick with short format) were: 1) There was no easy way of determining what size the long format vhpt cache should be automatically, and changing it dynamically would be too painful. Different workloads performed better with different size vhpt caches. 2) Regardless of the size, the vhpt cache is duplicated information. Using long format vhpt's significantly increased the number of cache misses for some workloads. Theoretically there should have been some cases where the long format solution would have performed better than the short format solution, but I was never able to create such a case. In many cases the performance difference between the long format solution and the short format solution was essentially the same. In other cases the short format vhpt solution outperformed the long format solution, and in those cases there was a significant difference in cache misses that I believe explained the performance difference. John -- 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/