From: John Marvin <jsm@fc.hp.com>
To: linux-ia64@vger.kernel.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: larger default page sizes...
Date: Tue, 25 Mar 2008 22:16:00 -0600 [thread overview]
Message-ID: <47E9CE00.7060106@fc.hp.com> (raw)
In-Reply-To: <87lk465mks.wl%peter@chubb.wattle.id.au>
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, 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-03-26 4:16 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 6:17 [00/14] Virtual Compound Page Support V3 Christoph Lameter
2008-03-21 6:17 ` [01/14] vcompound: Return page array on vunmap Christoph Lameter
2008-03-21 6:17 ` [02/14] vcompound: pageflags: Add PageVcompound() Christoph Lameter
2008-03-21 6:17 ` [03/14] vmallocinfo: Support display of vcompound for a virtual compound page Christoph Lameter
2008-03-21 7:55 ` Eric Dumazet
2008-03-21 17:32 ` Christoph Lameter
2008-03-21 6:17 ` [04/14] vcompound: Core piece Christoph Lameter
2008-03-22 12:10 ` KOSAKI Motohiro
2008-03-24 18:28 ` Christoph Lameter
2008-03-21 6:17 ` [05/14] vcompound: Debugging aid Christoph Lameter
2008-03-21 6:17 ` [06/14] vcompound: Virtual fallback for sparsemem Christoph Lameter
2008-03-21 6:17 ` [07/14] vcompound: bit waitqueue support Christoph Lameter
2008-03-21 6:17 ` [08/14] vcompound: Fallback for zone wait table Christoph Lameter
2008-03-21 6:17 ` [09/14] vcompound: crypto: Fallback for temporary order 2 allocation Christoph Lameter
2008-03-21 6:17 ` [10/14] vcompound: slub: Use for buffer to correlate allocation addresses Christoph Lameter
2008-03-21 6:17 ` [11/14] vcompound: Fallbacks for order 1 stack allocations on IA64 and x86 Christoph Lameter
2008-03-21 7:25 ` David Miller, Christoph Lameter
2008-03-21 8:39 ` Ingo Molnar
2008-03-21 17:33 ` Christoph Lameter
2008-03-21 19:02 ` Ingo Molnar
2008-03-21 19:04 ` Christoph Lameter
2008-03-21 17:40 ` Christoph Lameter
2008-03-21 21:57 ` David Miller, Christoph Lameter
2008-03-24 18:27 ` Christoph Lameter
2008-03-24 20:37 ` larger default page sizes David Miller, Christoph Lameter
2008-03-24 21:05 ` Christoph Lameter
2008-03-24 21:43 ` David Miller, Christoph Lameter
2008-03-25 17:48 ` Christoph Lameter
2008-03-25 23:22 ` David Miller, Christoph Lameter
2008-03-25 23:41 ` Peter Chubb
2008-03-25 23:49 ` David Miller, Peter Chubb
2008-03-26 0:25 ` Peter Chubb
2008-03-26 0:31 ` David Miller, Peter Chubb
2008-03-26 0:34 ` David Mosberger-Tang
2008-03-26 0:39 ` David Miller, David Mosberger-Tang
2008-03-26 0:57 ` Peter Chubb
2008-03-26 4:16 ` John Marvin [this message]
2008-03-26 4:36 ` David Miller, John Marvin
2008-03-24 21:25 ` Luck, Tony
2008-03-24 21:46 ` David Miller, Luck, Tony
2008-03-25 3:29 ` Paul Mackerras
2008-03-25 4:15 ` David Miller, Paul Mackerras
2008-03-25 11:50 ` Paul Mackerras
2008-03-25 23:32 ` David Miller, Paul Mackerras
2008-03-25 23:49 ` Luck, Tony
2008-03-26 0:16 ` David Miller, Luck, Tony
2008-03-26 15:54 ` Nish Aravamudan
2008-03-26 17:05 ` Luck, Tony
2008-03-26 18:54 ` Mel Gorman
2008-03-25 12:05 ` Andi Kleen
2008-03-25 21:27 ` Paul Mackerras
2008-03-26 5:24 ` Paul Mackerras
2008-03-26 15:59 ` Linus Torvalds
2008-03-27 1:08 ` Paul Mackerras
2008-03-26 17:56 ` Christoph Lameter
2008-03-26 23:21 ` David Miller, Christoph Lameter
2008-03-27 3:00 ` Paul Mackerras
2008-03-25 18:27 ` Dave Hansen
2008-03-24 21:13 ` [11/14] vcompound: Fallbacks for order 1 stack allocations on IA64 and x86 Luck, Tony
2008-03-25 17:42 ` Christoph Lameter
2008-03-25 19:09 ` Luck, Tony
2008-03-25 19:25 ` Christoph Lameter
2008-03-21 22:30 ` Andi Kleen
2008-03-24 19:53 ` Christoph Lameter
2008-03-25 7:51 ` Andi Kleen
2008-03-25 17:55 ` Christoph Lameter
2008-03-25 18:07 ` Andi Kleen
2008-03-21 6:17 ` [12/14] vcompound: Avoid vmalloc in e1000 driver Christoph Lameter
2008-03-21 17:27 ` Kok, Auke
2008-03-21 6:17 ` [13/14] vcompound: Use vcompound for swap_map Christoph Lameter
2008-03-21 21:25 ` Andi Kleen
2008-03-21 21:33 ` Christoph Lameter
2008-03-24 19:54 ` Christoph Lameter
2008-03-25 7:52 ` Andi Kleen
2008-03-25 17:45 ` Christoph Lameter
2008-03-25 17:55 ` Andi Kleen
2008-03-25 17:51 ` Christoph Lameter
2008-03-21 6:17 ` [14/14] vcompound: Avoid vmalloc for ehash_locks Christoph Lameter
2008-03-21 7:02 ` Eric Dumazet
2008-03-21 7:03 ` Christoph Lameter
2008-03-21 7:31 ` David Miller, Christoph Lameter
2008-03-21 7:42 ` Eric Dumazet
2008-03-21 7:31 ` David Miller, Eric Dumazet
2008-03-21 17:31 ` Christoph Lameter
2008-03-22 18:40 ` [00/14] Virtual Compound Page Support V3 Arjan van de Ven
2008-03-24 18:31 ` Christoph Lameter
2008-03-24 19:29 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E9CE00.7060106@fc.hp.com \
--to=jsm@fc.hp.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox