On Wed, Feb 24, 2010 at 7:10 PM, Anthony Liguori wrote:
> 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
> archite
> > 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
Hello,
I just want to note the fact that although Linux got it badly wrong,
according to POSIX, MADV_DONTNEED is _not_ supposed to drop the content
of the memory, but just to tune the write-back heuristics and such.
(see glibc's ./sysdeps/unix/sysv/linux/posix_madvise.c if you're not
convinced)
q
On 02/24/2010 02:59 PM, Blue Swirl wrote:
On 2/24/10, Anthony Liguori 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
On 2/24/10, Anthony Liguori 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 m
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 m
