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: <20130814161753.GB2706@gmail.com>
Date:	Thu, 15 Aug 2013 01:17:53 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Luigi Semenzato <semenzato@...gle.com>
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>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Pekka Enberg <penberg@...helsinki.fi>,
	Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH v6 0/5] zram/zsmalloc promotion

Hi Luigi,

On Wed, Aug 14, 2013 at 08:53:31AM -0700, Luigi Semenzato wrote:
> During earlier discussions of zswap there was a plan to make it work
> with zsmalloc as an option instead of zbud. Does zbud work for

AFAIR, it was not an optoin but zsmalloc was must but there were
several objections because zswap's notable feature is to dump
compressed object to real swap storage. For that, zswap needs to
store bounded objects in a zpage so that dumping could be bounded, too.
Otherwise, it could encounter OOM easily.

> compression factors better than 2:1?  I have the impression (maybe
> wrong) that it does not.  In our use of zram (Chrome OS) typical

Since zswap changed allocator from zsmalloc to zbud, I didn't follow
because I had no interest of low compressoin ratio allocator so
I have no idea of status of zswap at a moment but I guess it would be
still 2:1.

> overall compression ratios are between 2.5:1 and 3:1.  We would hate
> to waste that memory if we switch to zswap.

If you have real swap storage, zswap might be better although I have
no number but real swap is money for embedded system and it has sudden
garbage collection on firmware side if we use eMMC or SSD so that it
could affect system latency. Morever, if we start to use real swap,
maybe we should encrypt the data and it would be severe overhead(CPU
and Power).

And what I am considering after promoting for zram feature is
asynchronous I/O and it's possible because zram is block device.

Thanks!
-- 
Kind regards,
Minchan Kim
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ