[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Xen 3.0 x86 + PAE with > 16 GB RAM?
> -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > Keir Fraser > Sent: 09 January 2006 10:30 > To: Derrik Pates > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] Xen 3.0 x86 + PAE with > 16 GB RAM? > > > On 6 Jan 2006, at 22:21, Derrik Pates wrote: > > > Can this safely be increased? From my reading of the code, > it appears > > that it is set as it is because each gigabyte of installed RAM > > requires a megabyte of RAM to be set aside for mapping tables and > > such. If I just increase the value of MACHPHYS_MBYTES to 32 (for > > example), should Xen boot and work happily, just consuming more RAM > > for its mapping tables? > > > > Please Cc: me with your reply, as I'm not subscribed to this list > > currently. > > The memory layout of Xen is hardcoded in asm-x86/config.h, > and also in public/arch-x86_32.h. If the addresses of certain > critical structures are modified appropriately then things > should work fine. Of course Linux will end up with less > kernel virtual address space and hence less lowmem. If I understand things right, the V40z is an AMD Opteron based system, which means that you could run x86-64. Is there any particular reason you don't want to do this? This would give you 63TB (or is that 63-7 = 56TB?) or addressable memory, with full 32-bit compatibility for user-mode code. You'd obviously have to run the Guest Kernels in 64-bit mode as well... I'm not aware of any reason why this shouldn't be a "better" solution? -- Mats > > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |