[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170123062716.GF24581@js1304-P5Q-DELUXE>
Date: Mon, 23 Jan 2017 15:27:16 +0900
From: Joonsoo Kim <iamjoonsoo.kim@....com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: zhouxianrong <zhouxianrong@...wei.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
sergey.senozhatsky@...il.com, minchan@...nel.org,
ngupta@...are.org, Mi.Sophia.Wang@...wei.com, zhouxiyu@...wei.com,
weidu.du@...wei.com, zhangshiming5@...wei.com,
won.ho.park@...wei.com
Subject: Re: [PATCH] mm: extend zero pages to same element pages for zram
On Mon, Jan 23, 2017 at 01:03:47PM +0900, Sergey Senozhatsky wrote:
> On (01/23/17 11:58), Joonsoo Kim wrote:
> > Hello,
> >
> > On Sun, Jan 22, 2017 at 10:58:38AM +0800, zhouxianrong wrote:
> > > 1. memset is just set a int value but i want to set a long value.
> >
> > Sorry for late review.
> >
> > Do we really need to set a long value? I cannot believe that
> > long value is repeated in the page. Value repeatition is
> > usually done by value 0 or 1 and it's enough to use int. And, I heard
> > that value 0 or 1 is repeated in Android. Could you check the distribution
> > of the value in the same page?
>
> Hello Joonsoo,
>
> thanks for taking a look and for bringing this question up.
> so I kinda wanted to propose union of `ulong handle' with `uint element'
> and switching to memset(), but I couldn't figure out if that change would
> break detection of some patterns.
>
> /* Allocated for each disk page */
> struct zram_table_entry {
> - unsigned long handle;
> + union {
> + unsigned long handle;
> + unsigned int element;
> + };
> unsigned long value;
> };
Hello,
Think about following case in 64 bits kernel.
If value pattern in the page is like as following, we cannot detect
the same page with 'unsigned int' element.
AAAAAAAABBBBBBBBAAAAAAAABBBBBBBB...
4 bytes is 0xAAAAAAAA and next 4 bytes is 0xBBBBBBBB and so on.
However, as I said before, I think that it is uncommon case.
Thanks.
Powered by blists - more mailing lists