qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] linux guests and ksm performance


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] linux guests and ksm performance
Date: Fri, 24 Feb 2012 07:23:58 +0000

On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi <address@hidden> wrote:
> On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi <address@hidden> wrote:
>> On Thu, Feb 23, 2012 at 7:08 PM, address@hidden <address@hidden> wrote:
>>> Stefan Hajnoczi <address@hidden> schrieb:
>>>
>>>>On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven <address@hidden> wrote:
>>>>> However, in a virtual machine I have not observed the above slow down
>>>>to
>>>>> that extend
>>>>> while the benefit of zero after free in a virtualisation environment
>>>>is
>>>>> obvious:
>>>>>
>>>>> 1) zero pages can easily be merged by ksm or other technique.
>>>>> 2) zero (dup) pages are a lot faster to transfer in case of
>>>>migration.
>>>>
>>>>The other approach is a memory page "discard" mechanism - which
>>>>obviously requires more code changes than zeroing freed pages.
>>>>
>>>>The advantage is that we don't take the brute-force and CPU intensive
>>>>approach of zeroing pages.  It would be like a fine-grained ballooning
>>>>feature.
>>>>
>>>
>>> I dont think that it is cpu intense. All user pages are zeroed anyway, but 
>>> at allocation time it shouldnt be a big difference in terms of cpu power.
>>
>> It's easy to find a scenario where eagerly zeroing pages is wasteful.
>> Imagine a process that uses all of physical memory.  Once it
>> terminates the system is going to run processes that only use a small
>> set of pages.  It's pointless zeroing all those pages if we're not
>> going to use them anymore.
>
> Perhaps the middle path is to zero pages but do it after a grace
> timeout.  I wonder if this helps eliminate the 2-3% slowdown you
> noticed when compiling.

Gah, it's too early in the morning.  I don't think this timer actually
makes sense.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]