linux-kernel - [PATCH] zram: add zpool support v2

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-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jun 2016 22:42:06 +0800
From:	Geliang Tang <geliangtang@...il.com>
To:	Minchan Kim <minchan@...nel.org>, Nitin Gupta <ngupta@...are.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Dan Streetman <ddstreet@...e.org>,
	Vitaly Wool <vitalywool@...il.com>
Cc:	Geliang Tang <geliangtang@...il.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: [PATCH] zram: add zpool support v2

On Mon, Jun 13, 2016 at 11:11:00AM +0200, Vitaly Wool wrote:
> Den 8 juni 2016 6:33 em skrev "Dan Streetman" <ddstreet@...e.org>:
> >
> > On Wed, Jun 8, 2016 at 5:39 AM, Geliang Tang <geliangtang@...il.com>
> wrote:
> > > This patch adds zpool support for zram, it will allow us to use both
> > > the zpool api and directly zsmalloc api in zram.
> >
> > besides the problems below, this was discussed a while ago and I
> > believe Minchan is still against it, as nobody has so far shown what
> > the benefit to zram would be; zram doesn't need the predictability, or
> > evictability, of zbud or z3fold.
> 
> > Right.
> >
> > Geliang, I cannot ack without any *detail* that what's the problem of
> > zram/zsmalloc, why we can't fix it in zsmalloc itself.
> > The zbud and zsmalloc is otally different design to aim different goal
> > determinism vs efficiency so you can choose what you want between
> > zswap
> > and zram rather than mixing the features.
>
> I'd also probably Cc Vitaly Wool on this
>
> Well, I believe I have something to say here. z3fold is generally faster
> than zsmalloc which makes it a better choice for zram sometimes, e.g. when
> zram device is used for swap. Also,  z3fold and zbud do not require MMU so
> zram over these can be used on small Linux powered MMU-less IoT devices, as
> opposed to the traditional zram over zsmalloc. Otherwise I do agree with
> Dan.
> 
> >
> > It doesn't make sense for zram to conditionally use zpool; either it
> > uses it and thus has 'select ZPOOL' in its Kconfig entry, or it
> > doesn't use it at all.
> >
> > > +#endif
> >
> > first, no.  this obviously makes using zpool in zram completely pointless.
> >
> > second, did you test this?  the pool you're passing is the zpool, not
> > the zs_pool.  quite bad things will happen when this code runs.  There
> > is no way to get the zs_pool from the zpool object (that's the point
> > of abstraction, of course).
> >
> > The fact zpool doesn't have these apis (currently) is one of the
> > reasons against changing zram to use zpool.
> >

Thank you all for your reply. I updated the patch and I hope this is better.

Geliang Tang (1):
  zram: update zram to use zpool

 drivers/block/zram/Kconfig    |  3 ++-
 drivers/block/zram/zram_drv.c | 59 ++++++++++++++++++++++---------------------
 drivers/block/zram/zram_drv.h |  4 +--
 mm/zsmalloc.c                 | 12 +++++----
 4 files changed, 41 insertions(+), 37 deletions(-)

-- 
2.5.5