[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PAE issue (32-on-64 work)

  • To: Joe Bonasera <joe.bonasera@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 19 Oct 2006 17:24:11 +0100
  • Delivery-date: Thu, 19 Oct 2006 09:32:11 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbzmwJCQJX5WF+OEdulKgAX8io7RQ==
  • Thread-topic: [Xen-devel] PAE issue (32-on-64 work)

On 19/10/06 17:19, "Joe Bonasera" <joe.bonasera@xxxxxxx> wrote:

> The code path in Solaris currently supports 2 possibilities for PAE top level
> tables. The normal code we use on bare metal allocates only 1 page
> that all cpu's share for the the top level page table. For
> example, cpu0 uses the 1st four quads for its current process'
> L3, cpu1 uses the next four, etc. On context switch or cr3 reload
> we (re)copy in the 4 entries of the process for that CPU's section
> of the page.
> That code path is, as so much of the 32 bit PAE support, a special
> case. So it was easily turned off and made to just use
> an entire page for each unique top level L3 on Xen.  I did that just for
> my initial bring up on PAE Xen, but was hoping to go back to some
> form of the optimized version next.

You should just allocate a page-sized L3 per process and be done with it. A
page overhead per process is nothing to be concerned about (clearly the
overhead can be even bigger if, for example, you run 4-level tables on
x86_64). Recopying the L3 entries every TLB flush will *not* perform well on
current Xen.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.