linux-kernel - Re: [PATCH v7 0/5] zram/zsmalloc promotion

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: <521495E5.7010109@oracle.com>
Date:	Wed, 21 Aug 2013 18:26:45 +0800
From:	Bob Liu <bob.liu@...cle.com>
To:	Minchan Kim <minchan@...nel.org>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jens Axboe <axboe@...nel.dk>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>,
	Konrad Rzeszutek Wilk <konrad@...nok.org>,
	Luigi Semenzato <semenzato@...gle.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Pekka Enberg <penberg@...helsinki.fi>,
	Mel Gorman <mgorman@...e.de>, lliubbo@...il.com
Subject: Re: [PATCH v7 0/5] zram/zsmalloc promotion

On 08/21/2013 05:24 PM, Bob Liu wrote:
> Hi Minchan,
> 
> On 08/21/2013 02:16 PM, Minchan Kim wrote:
>> It's 7th trial of zram/zsmalloc promotion.
>> I rewrote cover-letter totally based on previous discussion.
>>
>> The main reason to prevent zram promotion was no review of
>> zsmalloc part while Jens, block maintainer, already acked
>> zram part.
>>
>> At that time, zsmalloc was used for zram, zcache and zswap so
>> everybody wanted to make it general and at last, Mel reviewed it
>> when zswap was submitted to merge mainline a few month ago.
>> Most of review was related to zswap writeback mechanism which
>> can pageout compressed page in memory into real swap storage
>> in runtime and the conclusion was that zsmalloc isn't good for
>> zswap writeback so zswap borrowed zbud allocator from zcache to
>> replace zsmalloc. The zbud is bad for memory compression ratio(2)
>> but it's very predictable behavior because we can expect a zpage
>> includes just two pages as maximum. Other reviews were not major. 
>> http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04334.html
>>
>> Zcache doesn't use zsmalloc either so zsmalloc's user is only
>> zram now so this patchset moves it into zsmalloc directory.
>> Recently, Bob tried to move zsmalloc under mm directory to unify
>> zram and zswap with adding pseudo block device in zswap(It's
>> very weired to me) but he was simple ignoring zram's block device
>> (a.k.a zram-blk) feature and considered only swap usecase of zram,
>> in turn, it lose zram's good concept.
>>
> 
> Yes, I didn't notice the feature that zram can be used as a normal block
> device.
> 
> 
>> Mel raised an another issue in v6, "maintainance headache".
>> He claimed zswap and zram has a similar goal that is to compresss
>> swap pages so if we promote zram, maintainance headache happens
>> sometime by diverging implementaion between zswap and zram
>> so that he want to unify zram and zswap. For it, he want zswap
>> to implement pseudo block device like Bob did to emulate zram so
>> zswap can have an advantage of writeback as well as zram's benefit.
> 
> If consider zram as a swap device only, I still think it's better to add
> a pseudo block device to zswap and just disable the writeback of zswap.
> 
> But I have no idea of zram's block device feature.
> 

BTW: I think the original/main purpose that zram was introduced is for
swapping. Is there any real users using zram as a normal block device
instead of swap?
For normal usage, maybe we can extend ramdisk with compression feature.

-- 
Regards,
-Bob
--
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/