Re: KSM Algorithm

[Izik Eidus <izik@qumranet.com>]

ציטוט Sukanto Ghosh:
>>> Are every guest pages scanned in KVM while using KSM or page-scanning
>>> and sharing is triggered on some event (low memory, etc) ?
>>>
>>>       
>> no, the scanning run all the time (with number pages to scan and sleep
>> parameters...)
>>     
>
> Does the scanner(s) run as separate kernel threads ?\
>   
it can run as kernel thread / or by ioctl runing from userspace
>
>   
>>> Is sharing done only between the pages which have been registered via
>>> KSM_REGISTER_MEMORY_REGION ?
>>>
>>>       
>> yes
>>
>>     
>>> What are these for ? KSM_CREATE_SHARED_MEMORY_AREA and KSM_CREATE_SCAN ?
>>>
>>>       
>> KSM_CREATE_SHARED_MEMORY_AREA - to register memory area to be scanned for
>> identical pages
>> KSM_CREATE_SCAN - to create the scanner that scan for this pages
>>     
>
>
> So kvm will create a scanner using KSM_CREATE_SCAN ioctl to /dev/ksm.
> kvm sets its parameters which specify the frequency of scan operation.
> Then, it tries to determine periodically from the shadow page tables
> about the guest memory region, and registers them with the /dev/ksm.
> The scanner as configured will scan the registered areas and will
> create COW shared pages for identical pages.
> Am I right ?
>   

yea

> Doesn't KSM notifies KVM about the shared pages so that KVM can update
> its sptes accordingly or is it done by KSM itself ?
>   

when using kvm, mmu notifiers is a must for ksm, (mmu notifiers update 
kvm about the changes in the host page table)

> What about KSM being used by someone other than KVM ? Does KSM updates
> the ptes of the shared pages itself ?
>   

it can be used by any application, it update the ptes of the host, what 
you mean by the shared pages itself?

>
>   
>>> Where are the shared pages kept ? In kernel memory ? Aren't the shared
>>> pages always pinned in RAM (due to same reasons for pinned shadowed
>>> pages) ?
>>>
>>>       
>> in the version that was sent to the list it was kernel memory (meaning
>> shared pages are not swappable
>> (just the pages that are shared not the pages that we scan, when they are
>> split beacuse of copy on write it become swappable again
>> new version that i will send soon the pages are normal anonymous/userspace
>> memory that is swappable
>>
>>     
>
> What is the strategy/method which you will use to represent the shared
> memory as normal anonymous/userspace memory ? Then, these pages must
> be staying at one of the guest's address-space (whose pages have been
>   
> shared) ?
>   


it possible due to another patch that i need to send, that allow modules 
register new reverse mapping call backs...,

>
>   
>>> How much is the overhead involved due to this ?
>>>
>>>       
>> depeand on the speed you tell it to scan, but the overhead is about ~5% for
>> common cases
>>     
>
> Can I know the typical values of the parameters : sleep time, no. of
> pages to scan, which you used to arrive at the above mentioned
> overhead.
>   

i think it is about 256 2000 (256 pages per 2000 usleep)
(note that most of the cpu is acutlay taken by the copying of the pages 
when a new shared page is created, i have possible way to change it and 
reduce the cpu even more
but i dont know if i want to do it) (it add more IFs to the fast path 
inside the mm)


>
>