WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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

<Prev in Thread] Current Thread [Next in Thread>