linux-kernel - RE: [PATCHv5 1/8] zsmalloc: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <69936094-e2fc-44bd-b179-f567e8681bec@default>
Date:	Mon, 25 Feb 2013 09:05:38 -0800 (PST)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	Minchan Kim <minchan@...nel.org>, Nitin Gupta <ngupta@...are.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.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>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Joe Perches <joe@...ches.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Subject: RE: [PATCHv5 1/8] zsmalloc: add to mm/

> From: Seth Jennings [mailto:sjenning@...ux.vnet.ibm.com]
> Sent: Friday, February 22, 2013 1:04 PM
> To: Joonsoo Kim
> Subject: Re: [PATCHv5 1/8] zsmalloc: add to mm/
> 
> On 02/22/2013 03:24 AM, Joonsoo Kim wrote:
> >
> > It's my quick thought. So there is no concrete idea.
> > As Seth said, with a FULL list, zsmalloc always access all zspage.
> > So, if we want to know what pages are for zsmalloc, we can know it.
> > The EMPTY list can be used for pool of zsmalloc itself. With it, we don't
> > need to free zspage directly, we can keep zspages, so can reduce
> > alloc/free overhead. But, I'm not sure whether it is useful.
> 
> I think it's a good idea.  zswap actually does this "keeping some free
> pages around for later allocations" outside zsmalloc in a mempool that
> zswap manages.  Minchan once mentioned bringing that inside zsmalloc
> and this would be a way we could do it.

I think it's a very bad idea.  If I understand, the suggestion will
hide away some quantity (possibly a very large quantity) of pages
for the sole purpose of zswap, in case zswap gets around to using them
sometime in the future.  In the meantime, those pages are not available
for use by any other kernel subsystems or by userland processes.
An idle page is a wasted page.

While you might defend the mempool use for a handful of pages,
frontswap writes/reads thousands of pages in a bursty way,
and then can go idle for a very long time.  This may not be
readily apparent with artificially-created memory pressure
from kernbench with -jN (high N).  Leaving thousands
of pages in zswap's personal free list may cause memory pressure
that would otherwise never have existed.

> Just want to be clear that I'd be in favor of looking at this after
> the merge.

I disagree... I think this is exactly the kind of fundamental
MM interaction that should be well understood and resolved
BEFORE anything gets merged.
--
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/