Re: [Xen-users] SMP and Memory Limits

[Gordan Bobic <gordan@xxxxxxxxxx>]

Petersson, Mats wrote:
> > > > > > What are the limits on how many CPUs and how much memory
> > > > Xen supports? 
> > > >
> > > > > > I am interested in this for both the host (0) kernel and 
> > the client
> >
> > > > > > (U) kernel.
> > > > > >
> > > > > > I am looking at getting some 16-way (8-way dual-core)
> > > > Opteron systems
> > > >
> > > >
> > > > > > with about 64 GB of RAM for prototyping, so I would like to
> > > > make sure
> > > >
> > > >
> > > > > > that Xen can use up all of the resources of such a machine.
> > > > > In Xen-unstable (to become 3.0) I believe there is no
> > > > software limits
> > > >
> > > >
> > > > > for CPU count or memory amount, only whatever limits the hardware 
> > > > > dictates (i.e. 40 bits of hardware address, 48 bits
> > > > available in virtual
> > > >
> > > >
> > > > > space). If there are any other limitations, it's probably fair to 
> > > > > consider it a bug, and report such failings on the 
> > Xen-Devel mailing 
> >
> > > > > list.
> > > > >
> > > > > Obviously, 2.0.x, only supporting 32-bit in non-PAE mode
> > > > would not be
> > > >
> > > >
> > > > > able to use more than about 3.5GB of RAM.
> > > > Is that 3.5 GB per dom-U/dom-0, or the total between dom-0 and all 
> > > > dom-Us put together?
> > > That would be 3.5 GB in total, since the only way to access 
> > more than 
> >
> > > this amount of memory would involve using address extended 
> > page table, 
> >
> > > which isn't supported by Xen 2.0.x. 64-bit x86 actually uses the 
> > > exisiting PAE, but with an added page-table level so that a bigger 
> > > than 36-bit address can be supported.
> > How stable is the "unstable/64-bit" version of Xen? Is it usable?
> I should think that it's usable as long as you don't expect your system
> to be a "production system with 100% 24/7 availability" [or somewhere
> where you'd have 100 angry users to answer to if the system goes down
> for more than half a minute]. Unstable should really be renamed into
> "testing" by now, as that's really what it is, but someone in XenSource
> decided that a rename of the directory was too much work... Or some
> such... The biggest problem would probably be obscure hardware or things
> that are rarely used in Xen, which I'm sure that there are some
> outstanding bugs and new ones to crop up in the near future. 
So, you are reasonably confident that when applied to a 64GB/16-way 
machine it isn't going to fall over flat on it's face? :-)
Gordan

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