linux-kernel - Re: [RFC 0/8]KVM: swap out guest pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Jul 2007 13:27:40 +0300
From:	Avi Kivity <avi@...ranet.com>
To:	Shaohua Li <shaohua.li@...el.com>
CC:	kvm-devel <kvm-devel@...ts.sourceforge.net>,
	lkml <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC 0/8]KVM: swap out guest pages

Shaohua Li wrote:
> This patch series make kvm guest pages be able to be swapped out and
> dynamically allocated. Without it, all guest memory is allocated at
> guest start time.
>
> patches are against latest git, and you need first patch Avi's kvm-sch
> integration patch
> (http://sourceforge.net/mailarchive/forum.php?thread_name=11841693332609-git-send-email-avi%40qumranet.com&forum_name=kvm-devel ).
>
> Patch is quite stable in my test. With the patch, I can run a 256M
> memory guest in a 300M memory host. 

What about the opposite?

> If guest is idle, the memory it used
> can be less than 10M. I did a simple performance test (measure kernel
> build time in guest), if there is few swap, the performance w/wo the
> patch difference isn't significent. If you have better measurement
> approach, please let me try.
>
> Unresolved issue:
> 1. swapoff doesn't work, we need a hook.
> 2. SMP guest might not work, as kvm doesn't support smp till now.
> 3. better algorithm to select swaped out guest pages according to
> guest's memory usage.
> Maybe more.
>
> Any suggests and comments are appreciated.
>   

The big question is whether to have kvm's own address_space or not.

Having an address_space (like your patch does) is remarkably simple, and 
requires few hooks from the current vm.  However using existing vmas 
mapped by the user has many advantages:

- compatible with s390 requirements
- allows the user to use hugetlbfs pages, which have a performance 
advantage using ept/npt (but which are unswappable)
- allows the user to map a file (which can be regarded as way to specify 
the swap device)
- better ingration with the rest of the vm

I am quite torn between the simplicity of your approach and the 
advantages of using generic vmas.  However, s390 pretty much forces our 
hand.

What is your opinion of extending generic vmas to back kvm guest memory?

-- 
error compiling committee.c: too many arguments to function

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/