linux-kernel - Re: [PATCH 7/8] zswap: add to mm/

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:	Fri, 04 Jan 2013 09:55:18 -0600
From:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
To:	Dave Chinner <david@...morbit.com>
CC:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nitin Gupta <ngupta@...are.org>,
	Minchan Kim <minchan@...nel.org>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	Robert Jennings <rcj@...ux.vnet.ibm.com>,
	Jenifer Hopper <jhopper@...ibm.com>,
	Mel Gorman <mgorman@...e.de>,
	Johannes Weiner <jweiner@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Larry Woodman <lwoodman@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [PATCH 7/8] zswap: add to mm/

On 01/03/2013 08:30 PM, Dave Chinner wrote:
>>> And so the two subsystems need different reclaim implementations.
>>> > > And, well, that's exactly what we have shrinkers for - implmenting
>>> > > subsystem specific reclaim policy. The shrinker infrastructure is
>>> > > responsible for them keeping balance between all the caches that
>>> > > have shrinkers and the size of the page cache...
>> > 
>> > Given the above, do you think either compressed-anonymous-pages or
>> > compressed-pagecache-pages are suitable candidates for the shrinker
>> > infrastructure?
> I don't know all the details of what you are trying to do, but you
> seem to be describing a two-level heirarchy - a pool of compressed
> data and a pool of uncompressed data, and under memory pressure are
> migrating data from the uncompressed pool to the compressed pool. On
> access, you are migrating back the other way.  Hence it seems to me
> that you could implement the process of migration from the
> uncompressed pool to the compressed pool as a shrinker so that it
> only happens as a result of memory pressure....

In our case, the mechanism for moving pages from the uncompressed pool
(anonymous memory) to the compressed pool is the swapping mechanism
itself.  The mechanism for moving pages the other way is the page
fault handler.

To summarize my ideas wrt to zswap and the shrinker interface, I don't
think there is a good use case here because all of the compressed
pages in zswap are conceptually dirty.  The writeback for these pages
is both slow (bio write) and requires memory allocation.  So zswap
isn't a cache in the usual sense, where cache contents are clean,
exist in RAM only for performance reasons, and can be freed in a
lightweight way at any time.

Thanks,
Seth

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