All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Mick.Jordan@sun.com
Cc: xen-devel@lists.xensource.com
Subject: Re: 2MB page PV guest support clarification
Date: Fri, 27 Feb 2009 15:28:15 -0800	[thread overview]
Message-ID: <49A8770F.6070806@goop.org> (raw)
In-Reply-To: <49A870E6.8050300@Sun.COM>

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.

> I found some posts from quite a while ago on xen-devel discussing 
> patches to allow large pages, so my question is for clarification  on 
> the status of this feature. I.e., is it in any stable release and if 
> so what version?

Its a work in progress, but there's nothing usable yet, as far as I know.

    J

  reply	other threads:[~2009-02-27 23:28 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 [this message]
2009-02-27 23:54   ` Mick Jordan
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=49A8770F.6070806@goop.org \
    --to=jeremy@goop.org \
    --cc=Mick.Jordan@sun.com \
    --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.