linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: zhouxianrong <zhouxianrong@huawei.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, sergey.senozhatsky@gmail.com,
	ngupta@vflare.org, Mi.Sophia.Wang@huawei.com,
	zhouxiyu@huawei.com, weidu.du@huawei.com,
	zhangshiming5@huawei.com, won.ho.park@huawei.com
Subject: Re: [PATCH] mm: extend zero pages to same element pages for zram
Date: Wed, 25 Jan 2017 10:29:05 +0900	[thread overview]
Message-ID: <20170125012905.GA17937@bbox> (raw)
In-Reply-To: <1ac33960-b523-1c58-b2de-8f6ddb3a5219@huawei.com>

Hi zhouxianrong,

On Tue, Jan 24, 2017 at 03:58:02PM +0800, zhouxianrong wrote:
> @@ -161,15 +161,55 @@ static bool page_zero_filled(void *ptr)
>  {
>  	unsigned int pos;
>  	unsigned long *page;
> +	static unsigned long total;
> +	static unsigned long zero;
> +	static unsigned long pattern_char;
> +	static unsigned long pattern_short;
> +	static unsigned long pattern_int;
> +	static unsigned long pattern_long;
> +	unsigned char *p_char;
> +	unsigned short *p_short;
> +	unsigned int *p_int;
> +	bool retval = false;
> +
> +	++total;
> 
>  	page = (unsigned long *)ptr;
> 
> -	for (pos = 0; pos != PAGE_SIZE / sizeof(*page); pos++) {
> -		if (page[pos])
> -			return false;
> +	for (pos = 0; pos < PAGE_SIZE / sizeof(unsigned long) - 1; ++pos) {
> +	       if (page[pos] != page[pos + 1])
> +	                return false;
>  	}
> 
> -	return true;
> +	p_char = (unsigned char *)ptr;
> +	p_short = (unsigned short *)ptr;
> +	p_int = (unsigned int *)ptr;
> +
> +	if (page[0] == 0) {
> +		++zero;
> +		retval = true;
> +	} else if (p_char[0] == p_char[1] &&
> +		       p_char[1] == p_char[2] &&
> +		       p_char[2] == p_char[3] &&
> +		       p_char[3] == p_char[4] &&
> +		       p_char[4] == p_char[5] &&
> +		       p_char[5] == p_char[6] &&
> +		       p_char[6] == p_char[7])
> +		++pattern_char;
> +	else if (p_short[0] == p_short[1] &&
> +		       p_short[1] == p_short[2] &&
> +		       p_short[2] == p_short[3])
> +		++pattern_short;
> +	else if (p_int[0] == p_int[1] &&
> +		       p_int[1] == p_int[2])
> +		++pattern_int;
> +	else {
> +		++pattern_long;
> +	}
> +
> +	pr_err("%lld %lld %lld %lld %lld %lld\n", zero, pattern_char, pattern_short, pattern_int, pattern_long, total);
> +
> +	return retval;
>  }
> 
> the result as listed below:
> 
> zero    pattern_char   pattern_short   pattern_int   pattern_long   total      (unit)
> 162989  14454          3534            23516         2769           3294399    (page)
> 

so, int covers 93%. As considering non-zero dedup hit ratio is low, I think *int* is
enough if memset is really fast. So, I'd like to go with 'int' if Sergey doesn't mind.

Please include the number in description and resend patch, zhouxianrong. :)

Thanks.

> statistics for the result:
> 
>          pattern zero  pattern char  pattern short  pattern int  pattern long
> AVERAGE  0.745696298   0.085937175   0.015957701    0.131874915  0.020533911
> STDEV    0.035623777   0.016892402   0.004454534    0.021657123  0.019420072
> MAX      0.973813421   0.222222222   0.021409518    0.211812245  0.176512625
> MIN      0.645431905   0.004634398   0              0            0
> 
> 
> On 2017/1/23 15:40, Minchan Kim wrote:
> >On Mon, Jan 23, 2017 at 04:13:39PM +0900, Sergey Senozhatsky wrote:
> >>On (01/23/17 15:27), Joonsoo Kim wrote:
> >>>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.
> >>
> >>yep, that's exactly the case that I though would be broken
> >>with a 4-bytes pattern matching. so my conlusion was that
> >>for 4 byte pattern we would have working detection anyway,
> >>for 8 bytes patterns we might have some extra matching.
> >>not sure if it matters that much though.
> >
> >It would be better for deduplication as pattern coverage is bigger
> >and we cannot guess all of patterns now so it would be never ending
> >story(i.e., someone claims 16bytes pattern matching would be better).
> >So, I want to make that path fast rather than increasing dedup ratio
> >if memset is really fast rather than open-looping. So in future,
> >if we can prove bigger pattern can increase dedup ratio a lot, then,
> >we could consider to extend it at the cost of make that path slow.
> >
> >In summary, zhouxianrong, please test pattern as Joonsoo asked.
> >So if there are not much benefit with 'long', let's go to the
> >'int' with memset. And Please resend patch if anyone dosn't oppose
> >strongly by the time.
> >
> >Thanks.
> >
> >
> >.
> >
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-01-25  1:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06  8:42 [PATCH] mm: extend zero pages to same element pages for zram zhouxianrong
2017-01-09 23:41 ` Minchan Kim
2017-01-13  4:24   ` Sergey Senozhatsky
2017-01-13  6:23     ` Minchan Kim
2017-01-13  6:36       ` Sergey Senozhatsky
2017-01-13  6:47         ` Minchan Kim
2017-01-13  7:02           ` Sergey Senozhatsky
2017-01-13  8:03             ` Minchan Kim
2017-01-13  8:29 ` zhouxianrong
2017-01-21  8:43   ` Sergey Senozhatsky
2017-01-22  2:58     ` zhouxianrong
2017-01-22  4:45       ` Sergey Senozhatsky
2017-01-23  2:58       ` Joonsoo Kim
2017-01-23  3:32         ` zhouxianrong
2017-01-23  4:03         ` Sergey Senozhatsky
2017-01-23  6:27           ` Joonsoo Kim
2017-01-23  7:13             ` Sergey Senozhatsky
2017-01-23  7:40               ` Minchan Kim
2017-01-24  7:58                 ` zhouxianrong
2017-01-25  1:29                   ` Minchan Kim [this message]
2017-01-25  1:32                     ` Sergey Senozhatsky
2017-01-25  2:48                       ` Matthew Wilcox
2017-01-25  4:18                         ` Sergey Senozhatsky
2017-01-25  4:51                           ` Minchan Kim
2017-01-25  5:38                             ` Sergey Senozhatsky
2017-01-25  5:44                               ` Minchan Kim
2017-01-23  6:26       ` Matthew Wilcox
2017-01-23  6:32         ` 答复: " zhouxianrong
2017-02-03  8:34 ` zhouxianrong
2017-02-03  8:42 ` zhouxianrong
2017-02-03 15:33   ` Matthew Wilcox
2017-02-04  3:33     ` zhouxianrong
2017-02-05 14:21   ` Minchan Kim
2017-02-06  1:28     ` zhouxianrong
2017-02-06 14:14       ` Matthew Wilcox
2017-02-06 23:48       ` Minchan Kim
2017-02-07  2:20         ` zhouxianrong
2017-02-07  2:54           ` Minchan Kim
2017-02-07  3:24             ` zhouxianrong
2017-02-07  4:57               ` Minchan Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170125012905.GA17937@bbox \
    --to=minchan@kernel.org \
    --cc=Mi.Sophia.Wang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=weidu.du@huawei.com \
    --cc=won.ho.park@huawei.com \
    --cc=zhangshiming5@huawei.com \
    --cc=zhouxianrong@huawei.com \
    --cc=zhouxiyu@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).