[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26E7A31274623843B0E8CF86148BFE326FB55F8B@NTXAVZMBX04.azit.micron.com>
Date: Mon, 2 Apr 2012 12:52:04 +0000
From: "Luca Porzio (lporzio)" <lporzio@...ron.com>
To: Hugh Dickins <hughd@...gle.com>, Arnd Bergmann <arnd@...db.de>
CC: Rik van Riel <riel@...hat.com>,
"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Alex Lemberg <alex.lemberg@...disk.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Saugata Das <saugata.das@...aro.org>,
Venkatraman S <venkat@...aro.org>,
Yejin Moon <yejin.moon@...sung.com>,
Hyojin Jeong <syr.jeong@...sung.com>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"kernel-team@...roid.com" <kernel-team@...roid.com>
Subject: RE: swap on eMMC and other flash
Hugh,
Great topics. As per one of Rik original points:
> 4) skip writeout of zero-filled pages - this can be a big help
> for KVM virtual machines running Windows, since Windows zeroes
> out free pages; simply discarding a zero-filled page is not
> at all simple in the current VM, where we would have to iterate
> over all the ptes to free the swap entry before being able to
> free the swap cache page (I am not sure how that locking would
> even work)
>
> with the extra layer of indirection, the locking for this scheme
> can be trivial - either the faulting process gets the old page,
> or it gets a new one, either way it'll be zero filled
>
Since it's KVMs realm here, can't KSM simply solve the zero-filled pages problem avoiding unnecessary burden for the Swap subsystem?
Cheers,
Luca
--
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