linux-kernel - Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux

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, 09 Jul 2009 16:41:40 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	npiggin@...e.de, akpm@...l.org, jeremy@...p.org,
	xen-devel@...ts.xensource.com, tmem-devel@....oracle.com,
	alan@...rguk.ukuu.org.uk, linux-mm@...ck.org,
	kurt.hackel@...cle.com, Rusty Russell <rusty@...tcorp.com.au>,
	dave.mccracken@...cle.com, Marcelo Tosatti <mtosatti@...hat.com>,
	sunil.mushran@...cle.com, Avi Kivity <avi@...hat.com>,
	Schwidefsky <schwidefsky@...ibm.com>, chris.mason@...cle.com,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux

Dan Magenheimer wrote:
> CMM2's focus is on increasing the number of VM's that
> can run on top of the hypervisor.  To do this, it
> depends on hints provided by Linux to surreptitiously
> steal memory away from Linux.  The stolen memory still
> "belongs" to Linux and if Linux goes to use it but the
> hypervisor has already given it to another Linux, the
> hypervisor must jump through hoops to give it back.
>   

It depends on how you define "jump through hoops".

> If it guesses wrong and overcommits too aggressively,
> the hypervisor must swap some memory to a "hypervisor
> swap disk" (which btw has some policy challenges).
> IMHO this is more of a "mainframe" model.
>   

No, not at all.  A guest marks a page as being "volatile", which tells 
the hypervisor it never needs to swap that page.  It can discard it 
whenever it likes.

If the guest later tries to access that page, it will get a special 
"discard fault".  For a lot of types of memory, the discard fault 
handler can then restore that page transparently to the code that 
generated the discard fault.

AFAICT, ephemeral tmem has the exact same characteristics as volatile 
CMM2 pages.  The difference is that tmem introduces an API to explicitly 
manage this memory behind a copy interface whereas CMM2 uses hinting and 
a special fault handler to allow any piece of memory to be marked in 
this way.

> In other words, CMM2, despite its name, is more of a
> "subservient" memory management system (Linux is
> subservient to the hypervisor) and tmem is more
> collaborative (Linux and the hypervisor share the
> responsibilities and the benefits/costs).
>   

I don't really agree with your analysis of CMM2.  We can map CMM2 
operations directly to ephemeral tmem interfaces so tmem is a subset of 
CMM2, no?

What's appealing to me about CMM2 is that it doesn't change the guest 
semantically but rather just gives the VMM more information about how 
the VMM is using it's memory.  This suggests that it allows greater 
flexibility in the long term to the VMM and more importantly, provides 
an easier implementation across a wide range of guests.

Regards,

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