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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 02 Apr 2009 16:05:22 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
CC:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	virtualization@...ts.linux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, virtualization@...ts.osdl.org,
	akpm@...l.org, frankeh@...son.ibm.com, hugh@...itas.com
Subject: Re: [patch 0/6] Guest page hinting version 7.

Nick Piggin wrote:
> On Friday 03 April 2009 06:06:31 Rik van Riel wrote:
>   
>> Ballooning has a simpler mechanism, but relies on an
>> as-of-yet undiscovered policy.
>>
>> Having experienced a zillion VM corner cases over the
>> last decade and a bit, I think I prefer a complex mechanism
>> over complex (or worse, unknown!) policy any day.
>>     
>
> I disagree with it being so clear cut. Volatile pagecache policy is completely
> out of the control of the Linux VM. Wheras ballooning does have to make some
> tradeoff between guests, but the actual reclaim will be driven by the guests.
> Neither way is perfect, but it's not like the hypervisor reclaim is foolproof
> against making a bad tradeoff between guests.
>   
I guess we could try to figure out a simple and robust policy
for ballooning.  If we can come up with a policy which nobody
can shoot holes in by just discussing it, it may be worth
implementing and benchmarking.

Maybe something based on the host passing memory pressure
on to the guests, and the guests having their own memory
pressure push back to the host.

I'l start by telling you the best auto-ballooning policy idea
I have come up with so far, and the (major?) hole in it.

Basically, the host needs the memory pressure notification,
where the VM will notify the guests when memory is running
low (and something could soon be swapped).  At that point,
each guest which receives the signal will try to free some
memory and return it to the host.

Each guest can have the reverse in its own pageout code.
Once memory pressure grows to a certain point (eg. when
the guest is about to swap something out), it could reclaim
a few pages from the host.

If all the guests behave themselves, this could work.

However, even with just reasonably behaving guests,
differences between the VMs in each guest could lead
to unbalanced reclaiming, penalizing better behaving
guests.

If one guest is behaving badly, it could really impact
the other guests.

Can you think of improvements to this idea?

Can you think of another balloon policy that does
not have nasty corner cases?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ