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]
Date:   Wed, 26 Apr 2017 15:59:38 +0900
From:   Joonsoo Kim <js1304@...il.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, kernel-team@....com
Subject: Re: [PATCH v4 2/4] zram: implement deduplication in zram

2017-04-26 15:29 GMT+09:00 Minchan Kim <minchan@...nel.org>:
> Hi Sergey and Joonsoo,
>
> On Wed, Apr 26, 2017 at 02:57:03PM +0900, Joonsoo Kim wrote:
>> On Wed, Apr 26, 2017 at 11:14:52AM +0900, Sergey Senozhatsky wrote:
>> > Hello,
>> >
>> > On (04/26/17 09:52), js1304@...il.com wrote:
>> > [..]
>> > >   ret = scnprintf(buf, PAGE_SIZE,
>> > > -                 "%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n",
>> > > +                 "%8llu %8llu %8llu %8lu %8ld %8llu %8lu %8llu %8llu\n",
>> > >                   orig_size << PAGE_SHIFT,
>> > >                   (u64)atomic64_read(&zram->stats.compr_data_size),
>> > >                   mem_used << PAGE_SHIFT,
>> > >                   zram->limit_pages << PAGE_SHIFT,
>> > >                   max_used << PAGE_SHIFT,
>> > >                   (u64)atomic64_read(&zram->stats.same_pages),
>> > > -                 pool_stats.pages_compacted);
>> > > +                 pool_stats.pages_compacted,
>> > > +                 zram_dedup_dup_size(zram),
>> > > +                 zram_dedup_meta_size(zram));
>> >
>> > hm... should't we subtract zram_dedup_dup_size(zram) from
>> > ->stats.compr_data_size? we don't use extra memory for dedupped
>> > pages. or don't inc ->stats.compr_data_size for dedupped pages?
>>
>> Hmm... My intention is to keep previous stat as much as possible. User
>> can just notice the saving by only checking mem_used.
>>
>> However, it's also odd that compr_data_size doesn't show actual
>> compressed data size.
>
> Actually, I found it for the last review cycle but didn't say that
> intentionally. Because it is also odd to me that pages_stored isn't
> increased for same_pages so I thought we can fix it all.
>
> I mean:
>
> * normal page
>         inc pages_stored
>         inc compr_data_size
> * same_page
>         inc pages_stored
>         inc same_pages
> * dedup_page
>         inc pages_stored
>         inc dup_data_size
>
> IOW, pages_stored should be increased for every write IO.
> But the concern is we have said in zram.txt
>
>  orig_data_size   uncompressed size of data stored in this disk.
>                   This excludes same-element-filled pages (same_pages) since
>                   no memory is allocated for them.
>
> So, we might be too late. :-(
> What do you think about it?
> If anyone doesn't have any objection, I want to correct it all.

I have no objection.
If so, do I need to postpone this patchset until others are fixed?

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ