linux-kernel - Re: [RFC] respect the referenced bit of KVM 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 06 Aug 2009 13:18:47 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
CC:	Wu Fengguang <fengguang.wu@...el.com>,
	Rik van Riel <riel@...hat.com>,
	"Dike, Jeffrey G" <jeffrey.g.dike@...el.com>,
	"Yu, Wilfred" <wilfred.yu@...el.com>,
	"Kleen, Andi" <andi.kleen@...el.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC] respect the referenced bit of KVM guest pages?

On 08/06/2009 01:08 PM, Andrea Arcangeli wrote:
> After some conversation it seems reactivating on large systems
> generates troubles to the VM as young bit have excessive time to be
> reactivated, giving troubles to shrink active list. I see that, so
> then the check should be still nuked, but the unconditional
> deactivation should happen instead. Otherwise it's trivial to put the
> VM to its knees and DoS it with a simple mmap of a file with MAP_EXEC
> as parameter of mmap. My whole point is that deciding if activating or
> deactivating pages can't be in function  of VM_EXEC, and clearly it
> helps on desktops but then it probably is a signal that the VM isn't
> good enough by itself to identify the important working set using
> young bits and stuff on desktop systems, and if there's a good reason
> to not activate, we shouldn't activate the VM_EXEC either as anything
> and anybody can generate a file mapping with VM_EXEC set...
>    

Reasonable; if you depend on a hint from userspace, that hint can be 
used against you.

> Likely we need a cut-off point, if we detect it takes more than X
> seconds to scan the whole active list, we start ignoring young bits,
> as young bits don't provide any meaningful information then and they
> just hang the VM in preventing it to shrink active list and looping
> over it endlessy with million pages inside that list. But on small
> systems if inactive list is short it may be too quick to just clear
> the young bit and only giving it time to be re-enabled in inactive
> list. That may be the source of the problem. Actually I'm speculating
> here, because I barely understood that this is swapin... not sure
> exactly what this regression is about but testing the patch posted is
> good idea and it will tell us if we just need to dynamically
> differentiating the algorithm between large and small systems and start
> ignoring young bits only at some point.
>    

How about, for every N pages that you scan, evict at least 1 page, 
regardless of young bit status?  That limits overscanning to a N:1 
ratio.  With N=250 we'll spend at most 25 usec in order to locate one 
page to evict.


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