Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751447Ab3HUK11 (ORCPT ); Wed, 21 Aug 2013 06:27:27 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:39869 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751174Ab3HUK1Z (ORCPT ); Wed, 21 Aug 2013 06:27:25 -0400 Message-ID: <521495E5.7010109@oracle.com> Date: Wed, 21 Aug 2013 18:26:45 +0800 From: Bob Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Minchan Kim CC: Greg Kroah-Hartman , Andrew Morton , Jens Axboe , Seth Jennings , Nitin Gupta , Konrad Rzeszutek Wilk , Luigi Semenzato , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg , Mel Gorman , lliubbo@gmail.com Subject: Re: [PATCH v7 0/5] zram/zsmalloc promotion References: <1377065791-2959-1-git-send-email-minchan@kernel.org> <52148730.4000709@oracle.com> In-Reply-To: <52148730.4000709@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2799 Lines: 63 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/