From: Mick Jordan <Mick.Jordan@sun.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: 2MB page PV guest support clarification
Date: Fri, 27 Feb 2009 15:54:43 -0800 [thread overview]
Message-ID: <49A87D43.7030006@Sun.COM> (raw)
In-Reply-To: <49A8770F.6070806@goop.org>
On 02/27/09 15:28, Jeremy Fitzhardinge wrote:
> Mick Jordan wrote:
>> I was inspired by the talk from Ben Serebrin at this weeks' summit to
>> investigate using 2MB pages in my Java VM on Xen for x86-64.
>>
>> I think I have done everything correctly, but Xen (3.1.4) rejects my
>> attempt to set the PSE bit in the L2 frame for the 2MB page. Looking
>> at the Xen code the L2_DISALLOW_MASK (0xFF800180U) simply rejects the
>> update if the PSE bit is set.
>
> Yes. Xen doesn't support large mappings for PV guests. However,
> there's a lot less to worry about for PV guests compared to hvm
> guests. A PV guest directly uses the CPU's pagetable+tlb hardware, and
> so a tlb miss results in a single simple walk of the pagetable, and
> the overall tlb pressure is a lot less. The desire to use large pages
> for hvm guests is driven by the cost of a tlb miss when you have 4k
> guest pages layered on 4k host pages, resulting in 24 memory accesses
> in the worst case; a PV tlb miss is no more expensive than a native
> tlb miss by comparison.
>
> Large pages could potentially reduce the cost of a PV tlb miss as
> well, but also pose quite a few tradeoffs. You can't generally use
> large mappings for the kernel, as you can native, because of all the
> pages which need RO mappings (pagetables, gdt, etc). Also, IO and the
> balloon driver operate at 4k page resolution, so breaking a contiguous
> 2M page would require the mapping to be shattered.
Well that's disappointing! The Java heap is a perfect candidate for
large pages and, since the heap tends to be large, would result in a
TLB size reduction of a factor of 512, thereby reducing the misses. I
have the luxury of a lot more semantics on memory usage than a typical
OS, so would only use large pages where it makes sense (heap and runtime
compiled code). I have my own equivalent of the balloon driver.
Mick
next prev parent reply other threads:[~2009-02-27 23:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-27 23:01 2MB page PV guest support clarification Mick Jordan
2009-02-27 23:28 ` Jeremy Fitzhardinge
2009-02-27 23:54 ` Mick Jordan [this message]
2009-02-28 0:03 ` Ian Pratt
2009-02-28 0:42 ` Mick Jordan
2009-02-28 1:28 ` Ian Pratt
2009-02-28 1:37 ` Mick Jordan
2009-03-02 10:44 ` Rolf Neugebauer
2009-02-28 11:12 ` Keir Fraser
2009-03-02 13:45 ` Dave McCracken
2009-03-02 16:38 ` Mick Jordan
2009-03-02 16:23 ` Mick Jordan
2009-03-02 16:34 ` Keir Fraser
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=49A87D43.7030006@Sun.COM \
--to=mick.jordan@sun.com \
--cc=jeremy@goop.org \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.