|
xen-devel
Re: [Xen-devel] understanding __linear_l2_table and friends
On Thu, Apr 21, 2005 at 02:51:34PM +0100, Ian Pratt wrote:
> PAE Linux currently uses a single L2 for all kernel mappings shared
> across all pagetables. Thus, when we do the mmu_ext_op hypercall to
> switch cr3 we'd need to write in new values into the appropriate L2 of
> the destination pagetable before re-loading cr3 (since in reality
> there'll only really ever be one such L2 for the domain, it makes sense
> to leave an open map_domain_mem to it.)
>
> The downside of this scheme is that it will cripple the TLB flush filter
> on Opteron. Linux used to do this until 2.6.11 anyhow, and no-one really
It also cripples the "adaptive cache" on
Intel systems, which assume that if two HT siblings have the same CR3
then the L1 cache can be shared. If that is false you get L1 cache
thrashing in some HT workloads.
> complained much. The far bigger problem is that it won't work for SMP
> guests, at least without making the L2 per VCPU and updating the L3
> accordingly using mm ref counting, which would be messy but do-able.
>
> The alternative is to hack PAE Linux to force the L2 containing kernel
> mappings to be per-pagetable rather than shared. The downside of the is
> that we use an extra 4KB per pagetable, and have the hassle of faulting
> in kernel L2 mappings on demand (like non-PAE Linux has to). This plays
> nicely with the TLB flush filter, and is fine for SMP guests.
>
> The simplest thing of all in the first instance is to turn all of the
> linear pagetable accesses into macros taking (exec_domain, offset) and
> then just implement them using pagetable walks.
>
> What do you guys think? Implement option #3 in the first instance, then
> aim for #2.
Since PAE is a temporary crock I would chose the least intrusive
variant to the codebase :)
-Andi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home