Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1610298

Re: [PATCH 4/4] zram: make deduplication feature optional

From Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Newsgroups linux.kernel
Subject Re: [PATCH 4/4] zram: make deduplication feature optional
Date 2017-03-28 07:20 +0200
Message-ID <tpRHX-2LM-7@gated-at.bofh.it> (permalink)
References (3 earlier) <to1ip-4sJ-3@gated-at.bofh.it> <tpy2C-51D-5@gated-at.bofh.it> <tpNO1-8qP-1@gated-at.bofh.it> <tpPd7-VD-3@gated-at.bofh.it> <tpPwt-12s-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello Minchan,

On (03/28/17 11:50), Minchan Kim wrote:
[..]
> > the reason I asked was that both zram and zswap sort of trying to
> > have same optimizations - zero filled pages handling, for example.
> > zram is a bit ahead now (to the best of my knowledge), because of
> > the recent 'same element' filled pages. zswap, probably, will have
> > something like this as well some day. or may be it won't, up to Seth
> > and Dan. de-duplication definitely can improve both zram and zswap,
> > which, once again, suggests that at some point zswap will have its
> > own implementation. well, or it won't.
> 
> As I pointed out, at least, dedup was no benefit for the swap case.
> I don't want to disrupt zsmalloc without any *proved* benefit.
> Even though it *might* have benefit, it shouldn't be in allocator
> layer unless it's really huge benefit like performance.

sure.

zpool, I meant zpool. I mistakenly used the word 'allocator'.

I meant some intermediate layer between zram and actual memory allocator,
a common layer which both zram and zswap can use and which can have
common functionality. just an idea. haven't really thought about it yet.

> It makes hard zram's allocator change in future.
> And please consider zswap is born for the latency in server workload
> while zram is memory efficiency in embedded world.

may be. I do suspect zswap is used in embedded as well [1]. there is even
a brand new allocator that 'reportedly' uses less memory than zsmalloc
and outperforms zsmalloc in embedded setups [1] (once again, reportedly.
I haven't tried it).

if z3fold is actually this good (I'm not saying it is not, haven't
tested it), then it makes sense to switch to zpool API in zram and let
zram users to select the allocator that fits their setups better.

just saying.


[1] http://events.linuxfoundation.org/sites/events/files/slides/zram1.pdf

	-ss

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 4/4] zram: make deduplication feature optional js1304@gmail.com - 2017-03-16 03:50 +0100
  Re: [PATCH 4/4] zram: make deduplication feature optional Minchan Kim <minchan@kernel.org> - 2017-03-22 01:10 +0100
    Re: [PATCH 4/4] zram: make deduplication feature optional Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2017-03-23 04:10 +0100
      Re: [PATCH 4/4] zram: make deduplication feature optional Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-27 10:20 +0200
        Re: [PATCH 4/4] zram: make deduplication feature optional Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2017-03-28 03:10 +0200
          Re: [PATCH 4/4] zram: make deduplication feature optional Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-28 04:40 +0200
            Re: [PATCH 4/4] zram: make deduplication feature optional Minchan Kim <minchan@kernel.org> - 2017-03-28 05:00 +0200
              Re: [PATCH 4/4] zram: make deduplication feature optional Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-03-28 07:20 +0200
                Re: [PATCH 4/4] zram: make deduplication feature optional Minchan Kim <minchan@kernel.org> - 2017-03-28 08:10 +0200

csiph-web