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: Peter Lieven
Subject: Re: [Qemu-devel] linux guests and ksm performance
Date: Fri, 24 Feb 2012 08:43:41 +0100

Am 24.02.2012 um 08:23 schrieb Stefan Hajnoczi:

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

ok, that would be the idea of an ansynchronous page zeroing in the guest. i also
think this is to complicated.

maybe the other idea is too simple:
is it possible to give the guest a hint that ksm is enabled on the host (lets 
say in
a way like its done with kvmclock). if ksm is enabled on the host the 
administrator
has already made the decision that performance is not so important and he/she
is eager to save physical memory. what if and only if this flag is set switch 
from
zero on allocate to zero after free. i think the whole thing is less than 10-20
lines of code. and its code that has been proven to be working well in 
grsecurity
for ages.

this might introduce a little (2-3%) overhead, but only if there is a lot of 
non GFP_FREE
memory is allocated, but its definitely faster than swapping. 
of course, it has to be garanteed that this code does not slow down normal 
systems
due to additionales branches (would it be enough to mark the if statements as 
unlikely?)

peter


peter





> 
> Stefan




reply via email to

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