linux-kernel - Re: [PATCHv5 4/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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5122B0A0.3090401@linux.vnet.ibm.com>
Date:	Mon, 18 Feb 2013 16:52:16 -0600
From:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Ric Mason <ric.masonn@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.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>,
	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 4/8] zswap: add to mm/

On 02/18/2013 03:59 PM, Dan Magenheimer wrote:
>> From: Seth Jennings [mailto:sjenning@...ux.vnet.ibm.com]
>> Subject: Re: [PATCHv5 4/8] zswap: add to mm/
>>
>> On 02/18/2013 01:55 PM, Dan Magenheimer wrote:
>>>> From: Seth Jennings [mailto:sjenning@...ux.vnet.ibm.com]
>>>> Subject: Re: [PATCHv5 4/8] zswap: add to mm/
>>>>
>>>> On 02/15/2013 10:04 PM, Ric Mason wrote:
>>>>>> + * certain event is occurring.
>>>>>> +*/
>>>>>> +static u64 zswap_pool_limit_hit;
>>>>>> +static u64 zswap_reject_compress_poor;
>>>>>> +static u64 zswap_reject_zsmalloc_fail;
>>>>>> +static u64 zswap_reject_kmemcache_fail;
>>>>>> +static u64 zswap_duplicate_entry;
>>>>>> +
>>>>>> +/*********************************
>>>>>> +* tunables
>>>>>> +**********************************/
>>>>>> +/* Enable/disable zswap (disabled by default, fixed at boot for
>>>>>> now) */
>>>>>> +static bool zswap_enabled;
>>>>>> +module_param_named(enabled, zswap_enabled, bool, 0);
>>>>>
>>>>> please document in Documentation/kernel-parameters.txt.
>>>>
>>>> Will do.
>>>
>>> Is that a good idea?  Konrad's frontswap/cleancache patches
>>> to fix frontswap/cleancache initialization so that backends
>>> can be built/loaded as modules may be merged for 3.9.
>>> AFAIK, module parameters are not included in kernel-parameters.txt.
>>
>> This is true.  However, the frontswap/cleancache init stuff isn't the
>> only reason zswap is built-in only.  The writeback code depends on
>> non-exported kernel symbols:
>>
>> swapcache_free
>> __swap_writepage
>> __add_to_swap_cache
>> swapcache_prepare
>> swapper_space
>> end_swap_bio_write
>>
>> I know a fix is as trivial as exporting them, but I didn't want to
>> take on that debate right now.
> 
> Hmmm... I wonder if exporting these might be the best solution
> as it (unnecessarily?) exposes some swap subsystem internals.
> I wonder if a small change to read_swap_cache_async might
> be more acceptable.

Yes, I'm not saying that I'm for exporting them; just that that would
be an easy and probably improper fix.

As I recall, the only thing I really needed to change in my adaption
of read_swap_cache_async(), zswap_get_swap_cache_page() in zswap, was
the assumption built in that it is swapping in a page on behalf of a
userspace program with the vma argument and alloc_page_vma().  Maybe
if we change it to just use alloc_page when vma is NULL, that could
work.  In a non-NUMA kernel alloc_page_vma() equals alloc_page() so I
wouldn't expect weird things doing that.

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/