[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAmzW4OPANWFbwNUm6eEhANvcNMbH0QUtxq=B-KoLuse-KzJVw@mail.gmail.com>
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