Re: [RFC] new totalmem= boot parameter

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Jul 20, 2010 at 02:26:16PM -0700, Sarina Canelake wrote:
> On Mon, Jul 19, 2010 at 07:11:19PM +0100, Keir Fraser wrote:
> > On 19/07/2010 18:56, "Sarina Canelake" <sarina.canelake@Oracle.Com> wrote:
> > 
> > > We have a need for ensuring the total RAM available to [Xen / the kernel] at
> > > boot is X MB because there are situations in which you wish to limit the
> > > amount of RAM available to a box. The existing mem= option doesn't work
> > > because it limits the maximum physical address, NOT the amount of available
> > > RAM. Many, if not all, systems contain a substantial memory hole below 4 Gb,
> > > typically a 0.5 or 1 Gb hole from 3-4 Gb. Thus, on a system with 6 Gb of RAM,
> > > requesting mem=4096M will yield a box with maximum physical address in the 4
> > > Gb neighborhood but perhaps only 3 or 3.5 actual gigs of RAM available.
> > 
> > It doesn't sound *very* useful. But then neither is mem= really. We can add
> > something like this if you really need it. So what's the motivation?
> > 
> 
> I found it useful while I was testing various core dumping capabilities.
> Using a boot-time argument to limit memory eliminates the need for pulling 
> out DIMMs (which I couldn't do anyways, as the machines I was working
> on are remote). However mem= didn't suffice for this purpose
> beyond 3 Gb since, as I mentioned, it limits the physical address 
> rather than the amount of RAM, which is what I thought it was 
> supposed to do. Hence the implementation of totalmem=, which made my 
> 16Gb+ boxes capable of imitating various, specific smaller configurations.
> 
> Alternatively, if mem= isn't used very frequently, perhaps it wouldn't 

I use it for testing combinations where memory below the 4GB mark (for
PCI devices) makes Dom0/DomU work. This helps to figure out what went
wrong. And that means I actually need RAM (and the PCI hole) to be below the
32-bit mark.