> > 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
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