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>
next prev parent 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).