linux-kernel - Re: Frontswap [PATCH 0/4] (was Transcendent Memory): overview

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] [day] [month] [year] [list]

Message-ID: <20100510180505.3e60e2da@mschwide.boeblingen.de.ibm.com>
Date:	Mon, 10 May 2010 18:05:05 +0200
From:	Martin Schwidefsky <schwidefsky@...ibm.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Avi Kivity <avi@...hat.com>, Pavel Machek <pavel@....cz>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, jeremy@...p.org,
	hugh.dickins@...cali.co.uk, ngupta@...are.org, JBeulich@...ell.com,
	chris.mason@...cle.com, kurt.hackel@...cle.com,
	dave.mccracken@...cle.com, npiggin@...e.de,
	akpm@...ux-foundation.org, riel@...hat.com
Subject: Re: Frontswap [PATCH 0/4] (was Transcendent Memory): overview

On Fri, 30 Apr 2010 09:08:00 -0700
Dave Hansen <dave@...ux.vnet.ibm.com> wrote:

> On Fri, 2010-04-30 at 08:59 -0700, Dan Magenheimer wrote:
> > Dave or others can correct me if I am wrong, but I think CMM2 also
> > handles dirty pages that must be retained by the hypervisor.  The
> > difference between CMM2 (for dirty pages) and frontswap is that
> > CMM2 sets hints that can be handled asynchronously while frontswap
> > provides explicit hooks that synchronously succeed/fail.
> 
> Once pages were dirtied (or I guess just slightly before), they became
> volatile, and I don't think the hypervisor could do anything with them.
> It could still swap them out like usual, but none of the CMM-specific
> optimizations could be performed.

Well, almost correct :-)
A dirty page (or one that is about to become dirty) can be in one of two
CMMA states:
1) stable
This is the case for pages where the kernel is doing some operation on
the page that will make it dirty, e.g. I/O. Before the kernel can
allow the operation the page has to be made stable. If the state
conversion to stable fails because the hypervisor removed the page the
page needs to get deleted from page cache and recreated from scratch.
2) potentially-volatile
This state is used for page cache pages for which a writable mapping
exists. The page can be removed by the hypervisor as long as the
physical per-page dirty bit is not set. As soon as the bit is set the
page is considered stable although the CMMA state still is potentially-
volatile.

In both cases the only thing the hypervisor can do with a dirty page is
to swap it as usual.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

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