This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 0 of 3] Patches for PCI passthrough with modi

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 0 of 3] Patches for PCI passthrough with modified E820 (v3) - resent.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Fri, 13 May 2011 09:57:08 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 13 May 2011 06:58:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1305276440.31488.60.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110509210140.GA29498@xxxxxxxxxxxx> <1305016202.26692.255.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110510145322.GA17128@xxxxxxxxxxxx> <1305040198.26692.286.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110510152751.GA13469@xxxxxxxxxxxx> <1305041579.26692.291.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110510155147.GA17563@xxxxxxxxxxxx> <1305100191.26692.306.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110512174133.GE11649@xxxxxxxxxxxx> <1305276440.31488.60.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
> > memhog 4G worked great.. but then I noticed it started slowing down and
> > it was using the swap disk?
> I guess the I/O holes shadowed the RAM and hence it is basically wasted.

> > Anyhow, seems that if you are using RHEL5, SLES11, you need to be carefull 
> > to
> > use 'memory' and 'maxmem'.
> Hrm, changing behaviour for existing guests isn't so nice, at least not
> without a way to turn the behaviour off, perhaps we do need an explicit
> cfg file variable to control this after all?

We could do that, and then once your idea below has been completly working
we can rip out the parameter?
> >  With the PVOPS, need to balloon up and you are OK.
> > 
> > Thought I do want to see about writting the code that would automatically 
> > balloon
> > back to the amount of memory that was deflated.
> I wonder if just writing the correct balloon target to xenstore while
> building the guest would be sufficient for the guest to balloon up once
> it's up?

Yeah, that way we can also fix the RHEL5, SLES11 ones too. Just subtract the
delta from the 'memory', put it in a variable ('target_now'?) that will be 
to the 'target' XenStore key (not sure if that was the correct name). However 
it also
implies that we need to do some extra steps with the P2M allocation _before_ we 
with the 'memory' value as the P2M allocation kicks of the populate_physmap and
we don't want it to shadow the I/O holes.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>