> > 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.
<nods>
> > 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
written
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
play
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home