From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC] new totalmem= boot parameter Date: Wed, 21 Jul 2010 08:46:11 +0100 Message-ID: References: <20100720212616.GB15056@ca-server1.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100720212616.GB15056@ca-server1.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sarina Canelake Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 20/07/2010 22:26, "Sarina Canelake" wrote: >> 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. Okay, I applied a reimplemented form of your patch as xen-unstable:21837. The option is named availmem rather than totalmem. I think it's a slightly better name. -- Keir > Alternatively, if mem= isn't used very frequently, perhaps it wouldn't > be a bad idea to simply update the functionality of mem= to limit the > total memory rather than the physical address.