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. So I propose to add a new kernel argument, which I call totalmem, that limits the total amount of memory available, ignoring holes. So requesting totalmem=4096M in the preceding example, the maximum physical address may extend much higher depending on the size of the memory map hole. An example patch is attached; it doesn''t apply directly to xen-unstable but should provide an example implementation for discussion; I implemented it to conform to the changes made to the clip_to_limit function in xen-unstable. Alternately, we could modify mem= to do this; according to documentation, it seems that the behavior of totalmem reflects the designer''s goal for mem. However, I would be worried about issues of backwards compatibility, as people may already be exploiting the current functionality of mem= to directly cut off the address space. Comments? (P.S. This is my first post to xen-devel so please be kind :) Thanks, Sarina _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 be a bad idea to simply update the functionality of mem= to limit the total memory rather than the physical address. Sarina> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Jul-20 21:55 UTC
Re: [Xen-devel] [RFC] new totalmem= boot parameter
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''tI 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 20/07/2010 22:26, "Sarina Canelake" <sarina.canelake@oracle.com> 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._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel