[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] PAE issue (32-on-64 work)
> >Why not just have a fixed per-vcpu L4 and L3, into which the 4 PAE L3's > >get copied on every cr3 load? > >It's most analogous to what happens today. > > In the shadowing (PAE, 32bit) case (a code path that, as I said, I'd rather > see ripped out). Why? It's essential to allow PAE PGDs to live above 4GB, which is a PITA otherwise. > In the general 64-bit case, this would add another > (needless) distinct code path. I think I still like better the idea of > clearing out the final 518 entries. > > >We've thought of removing the page-size restriction on PAE L3's in the > >past, but it's pretty low down the priority list as it typically doesn't > >cost a great deal of memory. > > Ah. I would have felt different. Most machines probably only have a hundred processes (we can exclude kernel threads and threads in general), hence maybe a few hundred KB wasted, tops. If we did remove the size restriction, we'd still want to put them in their own slab cache rather than the general 32b cache, as you don't want them being shared with other non-PGD data. This is a PITA that mandates how we handle shadowing of PAE PGDs in the HVM case where we can't control what they're allocated alongside. Ian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |