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:	Thu, 02 Apr 2009 12:58:33 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Rik van Riel <riel@...hat.com>
CC:	Martin Schwidefsky <schwidefsky@...ibm.com>, akpm@...l.org,
	Nick Piggin <nickpiggin@...oo.com.au>, frankeh@...son.ibm.com,
	virtualization@...ts.osdl.org, linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org, linux-mm@...ck.org,
	hugh@...itas.com, Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: [patch 0/6] Guest page hinting version 7.

Rik van Riel wrote:
> Page hinting has a complex, but well understood, mechanism
> and simple policy.
>   

For the guest perhaps, and yes, it does push the problem out to the 
host.  But that doesn't make solving a performance problem any easier if 
you end up in a mess.

> Ballooning has a simpler mechanism, but relies on an
> as-of-yet undiscovered policy.
>   
(I'm talking about Xen ballooning here; I know KVM ballooning works 
differently.)

Yes and no.  If you want to be able to shrink the guest very 
aggressively, then you need to be very careful about not shrinking too 
much for its current and near-future needs.  But you'll get into an 
equivalently bad state with page hinting if the host decides to swap out 
and discard lots of persistent guest pages.

When the host demands memory from the guest, the simple caseballooning 
is analogous to page hinting:

    * give up free pages == mark pages unused
    * give up clean pages == mark pages volatile
    * cause pressure to release some memory == host swapping

The flipside is how guests can ask for memory if their needs increase 
again.  Page-hinting is fault-driven, so the guest may stall while the 
host sorts out some memory to back the guests pages.  Ballooning 
requires the guest to explicitly ask for memory, and that could be done 
in advance if it notices the pool of easily-freed pages is shrinking 
rapidly (though I guess it could be done on demand as well, but we don't 
have hooks for that).

But of course, there are other approaches people are playing with, like 
Dan Magenheimer's transcendental memory, which is a pool of 
hypervisor-owned and managed pages which guests can use via a copy 
interface, as a second-chance page discard cache, fast swap, etc.  Such 
mechanisms may be easier on both the guest complexity and policy fronts.

The more complex host policy decisions of how to balance overall memory 
use system-wide are much in the same for both mechanisms.

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