RE: [Xen-devel] RE: tmem - really default to on?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Further, I believe switching to 2Mb chunks just changes the problem
from external fragmentation to internal fragmentation... or
re-requires (for x86_64) keeping separate allocation pools for
xenheap and domheap.

> able to look at it immediately but maybe Christian has a patch.

/me looks hopefully in Christian's direction...

> -----Original Message-----
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Tuesday, February 09, 2010 6:59 AM
> To: Keir Fraser
> Cc: Jan Beulich; Christian Limpach; xen-devel@xxxxxxxxxxxxxxxxxxx; Dan
> Magenheimer
> Subject: Re: [Xen-devel] RE: tmem - really default to on?
> 
> At 13:31 +0000 on 09 Feb (1265722267), Keir Fraser wrote:
> > On 09/02/2010 13:00, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> >
> > >> I think the correct approach to all of this is to move system-wide
> to
> > >> allocating memory in 2MB contiguous aligned chunks.  There's no
> sense in
> > >> doing guest allocations any finer-grained than that and there are
> > >> noticeable performance wins from all the superpage support that's
> gone
> > >> in recently.  Then little things like needing 16k contiguous areas
> just
> > >> go away.
> > >
> > > I have to admit that I can't see how this would work with
> ballooning,
> > > or (if the balloon driver was adjusted to deal with this) with
> > > fragmentation inside Dom0 (or any other guest that memory is
> > > intended to be removed from). Nor am I sure tmem could be
> > > changed to deal with 2Mb chunks instead of 4k ones.
> >
> > Balloon driver is the obvious fly in the ointment that I can see,
> too.
> 
> Good point.  That's going to be a problem for HVM ballooning,
> especially
> on EPT/NPT where having superpage allocations makes a big difference.
> 
> In the meantime we can fix the shadow code.  Unfortunately I won't be
> able to look at it immediately but maybe Christian has a patch.
> 
> Tim.
> 
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, XenServer Engineering
> Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel