On 02/24/2010 02:59 PM, Blue Swirl wrote:
On 2/24/10, Anthony Liguori<aligu...@us.ibm.com> wrote:
If you compare the RSS of a freshly booted guest and the same guest after a
reboot, it's very likely the freshly booted guest will have an RSS that is
much lower the the rebooted guest because the previous run of the guest
faulted
in all available memory.
This patch addresses this issue by using madvise() during reset. It only
resets RAM areas which means it has to be done in the machine. I've only done
this for the x86 target because I'm fairly confident that this is allowed
architecturally on x86 although I'm not sure this is universely true.
This does not appear to have an observable cost with a large memory guest and
I can't really think of any down sides.
I think it would be much cleaner to make the madvise() calls from
exec.c, now you are duplicating some of the functionality there. The
calls could be controlled by a global variable (set only in pc.c) so
non-PC architectures would not be disturbed.
One thing we could do (that I think has other uses) is to add a context
parameter to qemu_ram_alloc(). We could start with a simple flag of
something like QRAM_RAM and QRAM_ROM. QRAM_RAM would get automatically
madvise()'d on reset.
But that said, does anyone know of an architecture where this type of
reset would be a problem? Would it be a problem on sparc?
Regards,
Anthony Liguori
