All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] KSM: Replace jhash2 with xxhash
@ 2017-09-21  7:45 Timofey Titovets
  2017-09-21 15:36 ` Andi Kleen
  2017-09-22  8:44 ` Christian Borntraeger
  0 siblings, 2 replies; 7+ messages in thread
From: Timofey Titovets @ 2017-09-21  7:45 UTC (permalink / raw)
  To: linux-mm; +Cc: Timofey Titovets

xxhash much faster then jhash,
ex. for x86_64 host:
PAGE_SIZE: 4096, loop count: 1048576
jhash2:   0xacbc7a5b            time: 1907 ms,  th:  2251.9 MiB/s
xxhash32: 0x570da981            time: 739 ms,   th:  5809.4 MiB/s
xxhash64: 0xa1fa032ab85bbb62    time: 371 ms,   th: 11556.6 MiB/s

xxhash64 on x86_32 work with ~ same speed as jhash2.
xxhash32 on x86_32 work with ~ same speed as for x86_64

So replace jhash with xxhash,
and use fastest version for current target ARCH.

Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
---
 mm/Kconfig |  1 +
 mm/ksm.c   | 25 ++++++++++++++++++-------
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 9c4bdddd80c2..252ab266ac23 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -305,6 +305,7 @@ config MMU_NOTIFIER
 config KSM
 	bool "Enable KSM for page merging"
 	depends on MMU
+	select XXHASH
 	help
 	  Enable Kernel Samepage Merging: KSM periodically scans those areas
 	  of an application's address space that an app has advised may be
diff --git a/mm/ksm.c b/mm/ksm.c
index 15dd7415f7b3..e012d9778c18 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -25,7 +25,8 @@
 #include <linux/pagemap.h>
 #include <linux/rmap.h>
 #include <linux/spinlock.h>
-#include <linux/jhash.h>
+#include <linux/xxhash.h>
+#include <linux/bitops.h> /* BITS_PER_LONG */
 #include <linux/delay.h>
 #include <linux/kthread.h>
 #include <linux/wait.h>
@@ -51,6 +52,12 @@
 #define DO_NUMA(x)	do { } while (0)
 #endif
 
+#if BITS_PER_LONG == 64
+typedef	u64	xxhash;
+#else
+typedef	u32	xxhash;
+#endif
+
 /*
  * A few notes about the KSM scanning process,
  * to make it easier to understand the data structures below:
@@ -186,7 +193,7 @@ struct rmap_item {
 	};
 	struct mm_struct *mm;
 	unsigned long address;		/* + low bits used for flags below */
-	unsigned int oldchecksum;	/* when unstable */
+	xxhash oldchecksum;		/* when unstable */
 	union {
 		struct rb_node node;	/* when node of unstable tree */
 		struct {		/* when listed from stable tree */
@@ -255,7 +262,7 @@ static unsigned int ksm_thread_pages_to_scan = 100;
 static unsigned int ksm_thread_sleep_millisecs = 20;
 
 /* Checksum of an empty (zeroed) page */
-static unsigned int zero_checksum __read_mostly;
+static xxhash zero_checksum __read_mostly;
 
 /* Whether to merge empty (zeroed) pages with actual zero pages */
 static bool ksm_use_zero_pages __read_mostly;
@@ -982,11 +989,15 @@ static int unmerge_and_remove_all_rmap_items(void)
 }
 #endif /* CONFIG_SYSFS */
 
-static u32 calc_checksum(struct page *page)
+static xxhash calc_checksum(struct page *page)
 {
-	u32 checksum;
+	xxhash checksum;
 	void *addr = kmap_atomic(page);
-	checksum = jhash2(addr, PAGE_SIZE / 4, 17);
+#if BITS_PER_LONG == 64
+	checksum = xxh64(addr, PAGE_SIZE, 0);
+#else
+	checksum = xxh32(addr, PAGE_SIZE, 0);
+#endif
 	kunmap_atomic(addr);
 	return checksum;
 }
@@ -1994,7 +2005,7 @@ static void cmp_and_merge_page(struct page *page, struct rmap_item *rmap_item)
 	struct page *tree_page = NULL;
 	struct stable_node *stable_node;
 	struct page *kpage;
-	unsigned int checksum;
+	xxhash checksum;
 	int err;
 	bool max_page_sharing_bypass = false;
 
-- 
2.14.1

--
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>

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] KSM: Replace jhash2 with xxhash
  2017-09-21  7:45 [PATCH] KSM: Replace jhash2 with xxhash Timofey Titovets
@ 2017-09-21 15:36 ` Andi Kleen
  2017-09-21 17:35   ` Timofey Titovets
  2017-09-22  8:44 ` Christian Borntraeger
  1 sibling, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2017-09-21 15:36 UTC (permalink / raw)
  To: Timofey Titovets; +Cc: linux-mm

Timofey Titovets <nefelim4ag@gmail.com> writes:

> xxhash much faster then jhash,
> ex. for x86_64 host:
> PAGE_SIZE: 4096, loop count: 1048576
> jhash2:   0xacbc7a5b            time: 1907 ms,  th:  2251.9 MiB/s
> xxhash32: 0x570da981            time: 739 ms,   th:  5809.4 MiB/s
> xxhash64: 0xa1fa032ab85bbb62    time: 371 ms,   th: 11556.6 MiB/s
>
> xxhash64 on x86_32 work with ~ same speed as jhash2.
> xxhash32 on x86_32 work with ~ same speed as for x86_64

Which CPU is that?

>
> So replace jhash with xxhash,
> and use fastest version for current target ARCH.

Can you do some macro-benchmarking too? Something that uses
KSM and show how the performance changes.

You could manually increase the scan rate to make it easier
to see.

> @@ -51,6 +52,12 @@
>  #define DO_NUMA(x)	do { } while (0)
>  #endif
>  
> +#if BITS_PER_LONG == 64
> +typedef	u64	xxhash;
> +#else
> +typedef	u32	xxhash;
> +#endif

This should be in xxhash.h ? 

xxhash_t would seem to be a better name.

> -	u32 checksum;
> +	xxhash checksum;
>  	void *addr = kmap_atomic(page);
> -	checksum = jhash2(addr, PAGE_SIZE / 4, 17);
> +#if BITS_PER_LONG == 64
> +	checksum = xxh64(addr, PAGE_SIZE, 0);
> +#else
> +	checksum = xxh32(addr, PAGE_SIZE, 0);
> +#endif

This should also be generic in xxhash.h



-Andi

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KSM: Replace jhash2 with xxhash
  2017-09-21 15:36 ` Andi Kleen
@ 2017-09-21 17:35   ` Timofey Titovets
  2017-09-21 20:05     ` Andi Kleen
  0 siblings, 1 reply; 7+ messages in thread
From: Timofey Titovets @ 2017-09-21 17:35 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-mm

2017-09-21 18:36 GMT+03:00 Andi Kleen <ak@linux.intel.com>:
> Timofey Titovets <nefelim4ag@gmail.com> writes:
>
>> xxhash much faster then jhash,
>> ex. for x86_64 host:
>> PAGE_SIZE: 4096, loop count: 1048576
>> jhash2:   0xacbc7a5b            time: 1907 ms,  th:  2251.9 MiB/s
>> xxhash32: 0x570da981            time: 739 ms,   th:  5809.4 MiB/s
>> xxhash64: 0xa1fa032ab85bbb62    time: 371 ms,   th: 11556.6 MiB/s
>>
>> xxhash64 on x86_32 work with ~ same speed as jhash2.
>> xxhash32 on x86_32 work with ~ same speed as for x86_64
>
> Which CPU is that?

Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
---
I've access to some VM (Not KVM) with:
Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
PAGE_SIZE: 4096, loop count: 1048576
jhash2:   0x15433d14            time: 3661 ms,  th: 1173.144082 MiB/s
xxhash32: 0x3df3de36            time: 1163 ms,  th: 3691.581922 MiB/s
xxhash64: 0x5d9e67755d3c9a6a    time: 715 ms,   th: 6006.628034 MiB/s

As additional info, xxhash work with ~ same as jhash2 speed at 32 byte
input data.
For input smaller than 32 byte, jhash2 win, for input bigger, xxhash win.


>> So replace jhash with xxhash,
>> and use fastest version for current target ARCH.
>
> Can you do some macro-benchmarking too? Something that uses
> KSM and show how the performance changes.
>
> You could manually increase the scan rate to make it easier
> to see.

Try use that patch with my patch to allow process all VMA on system [1].
I switch sleep_millisecs 20 -> 1

(I use htop to see CPU load of ksmd)

CPU: Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
For jhash2: ~18%
For xxhash64: ~11%

(i didn't have x86_32 test machine, so by extrapolating values,
so i expect for xxhash32: (18+11)/2 = ~14.5%)

KSM Statistic:
full_scans:481
max_page_sharing:256
merge_across_nodes:1
mode:[always] normal
pages_shared:39
pages_sharing:135
pages_to_scan:100
pages_unshared:4514
pages_volatile:310
run:1
sleep_millisecs:1
stable_node_chains:0
stable_node_chains_prune_millisecs:2000
stable_node_dups:0
use_zero_pages:0

>> @@ -51,6 +52,12 @@
>>  #define DO_NUMA(x)   do { } while (0)
>>  #endif
>>
>> +#if BITS_PER_LONG == 64
>> +typedef      u64     xxhash;
>> +#else
>> +typedef      u32     xxhash;
>> +#endif
>
> This should be in xxhash.h ?

This is a "hack", for compile time chose appropriate hash function.
xxhash ported from upstream code,
upstream version don't do that (IMHO), as this useless in most cases.
That only can be useful for memory only hashes.
Because for persistent data it's obvious to always use one hash type 32/64.

> xxhash_t would seem to be a better name.
>
>> -     u32 checksum;
>> +     xxhash checksum;
>>       void *addr = kmap_atomic(page);
>> -     checksum = jhash2(addr, PAGE_SIZE / 4, 17);
>> +#if BITS_PER_LONG == 64
>> +     checksum = xxh64(addr, PAGE_SIZE, 0);
>> +#else
>> +     checksum = xxh32(addr, PAGE_SIZE, 0);
>> +#endif
>
> This should also be generic in xxhash.h

This *can* be generic in xxhash.h, when that solution will be used
somewhere in the kernel code, not in the KSM only, not?

Because for now i didn't find other places with "big enough" input
data, to replace jhash2 with xxhash.

>
>
> -Andi

Thanks.

Links:
1. https://marc.info/?l=linux-mm&m=150539825420373&w=2

-- 
Have a nice day,
Timofey.

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KSM: Replace jhash2 with xxhash
  2017-09-21 17:35   ` Timofey Titovets
@ 2017-09-21 20:05     ` Andi Kleen
  2017-09-21 21:37       ` Timofey Titovets
  0 siblings, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2017-09-21 20:05 UTC (permalink / raw)
  To: Timofey Titovets; +Cc: linux-mm

> > Which CPU is that?
> 
> Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
> ---
> I've access to some VM (Not KVM) with:
> Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
> PAGE_SIZE: 4096, loop count: 1048576
> jhash2:   0x15433d14            time: 3661 ms,  th: 1173.144082 MiB/s
> xxhash32: 0x3df3de36            time: 1163 ms,  th: 3691.581922 MiB/s
> xxhash64: 0x5d9e67755d3c9a6a    time: 715 ms,   th: 6006.628034 MiB/s
> 
> As additional info, xxhash work with ~ same as jhash2 speed at 32 byte
> input data.
> For input smaller than 32 byte, jhash2 win, for input bigger, xxhash win.

Please put that information into the changelog when you repost.

> 
> 
> >> So replace jhash with xxhash,
> >> and use fastest version for current target ARCH.
> >
> > Can you do some macro-benchmarking too? Something that uses
> > KSM and show how the performance changes.
> >
> > You could manually increase the scan rate to make it easier
> > to see.
> 
> Try use that patch with my patch to allow process all VMA on system [1].
> I switch sleep_millisecs 20 -> 1
> 
> (I use htop to see CPU load of ksmd)
> 
> CPU: Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
> For jhash2: ~18%
> For xxhash64: ~11%

Ok that's a great result. Is a speedup also visible with the default
sleep_millisecs value? 

> >> @@ -51,6 +52,12 @@
> >>  #define DO_NUMA(x)   do { } while (0)
> >>  #endif
> >>
> >> +#if BITS_PER_LONG == 64
> >> +typedef      u64     xxhash;
> >> +#else
> >> +typedef      u32     xxhash;
> >> +#endif
> >
> > This should be in xxhash.h ?
> 
> This is a "hack", for compile time chose appropriate hash function.
> xxhash ported from upstream code,
> upstream version don't do that (IMHO), as this useless in most cases.
> That only can be useful for memory only hashes.
> Because for persistent data it's obvious to always use one hash type 32/64.

I don't think it's a hack. It makes sense. Just should be done centrally
in Linux, not in a specific user.
> 
> > xxhash_t would seem to be a better name.
> >
> >> -     u32 checksum;
> >> +     xxhash checksum;
> >>       void *addr = kmap_atomic(page);
> >> -     checksum = jhash2(addr, PAGE_SIZE / 4, 17);
> >> +#if BITS_PER_LONG == 64
> >> +     checksum = xxh64(addr, PAGE_SIZE, 0);
> >> +#else
> >> +     checksum = xxh32(addr, PAGE_SIZE, 0);
> >> +#endif
> >
> > This should also be generic in xxhash.h
> 
> This *can* be generic in xxhash.h, when that solution will be used
> somewhere in the kernel code, not in the KSM only, not?

Yes.

> 
> Because for now i didn't find other places with "big enough" input
> data, to replace jhash2 with xxhash.

Right, but we may get them.

-Andi

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KSM: Replace jhash2 with xxhash
  2017-09-21 20:05     ` Andi Kleen
@ 2017-09-21 21:37       ` Timofey Titovets
  2017-09-21 22:06         ` Andi Kleen
  0 siblings, 1 reply; 7+ messages in thread
From: Timofey Titovets @ 2017-09-21 21:37 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-mm

2017-09-21 23:05 GMT+03:00 Andi Kleen <ak@linux.intel.com>:
>> > Which CPU is that?
>>
>> Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
>> ---
>> I've access to some VM (Not KVM) with:
>> Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
>> PAGE_SIZE: 4096, loop count: 1048576
>> jhash2:   0x15433d14            time: 3661 ms,  th: 1173.144082 MiB/s
>> xxhash32: 0x3df3de36            time: 1163 ms,  th: 3691.581922 MiB/s
>> xxhash64: 0x5d9e67755d3c9a6a    time: 715 ms,   th: 6006.628034 MiB/s
>>
>> As additional info, xxhash work with ~ same as jhash2 speed at 32 byte
>> input data.
>> For input smaller than 32 byte, jhash2 win, for input bigger, xxhash win.
>
> Please put that information into the changelog when you repost.
>
>>
>>
>> >> So replace jhash with xxhash,
>> >> and use fastest version for current target ARCH.
>> >
>> > Can you do some macro-benchmarking too? Something that uses
>> > KSM and show how the performance changes.
>> >
>> > You could manually increase the scan rate to make it easier
>> > to see.
>>
>> Try use that patch with my patch to allow process all VMA on system [1].
>> I switch sleep_millisecs 20 -> 1
>>
>> (I use htop to see CPU load of ksmd)
>>
>> CPU: Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
>> For jhash2: ~18%
>> For xxhash64: ~11%
>
> Ok that's a great result. Is a speedup also visible with the default
> sleep_millisecs value?

With defaults:
jhash2: ~4.7%
xxhash64: ~3.3%

3.3/4.7 ~= 0.7 -> Profit: ~30%
11/18   ~= 0.6 -> Profit: ~40%
(if i calculate correctly of course)

>> >> @@ -51,6 +52,12 @@
>> >>  #define DO_NUMA(x)   do { } while (0)
>> >>  #endif
>> >>
>> >> +#if BITS_PER_LONG == 64
>> >> +typedef      u64     xxhash;
>> >> +#else
>> >> +typedef      u32     xxhash;
>> >> +#endif
>> >
>> > This should be in xxhash.h ?
>>
>> This is a "hack", for compile time chose appropriate hash function.
>> xxhash ported from upstream code,
>> upstream version don't do that (IMHO), as this useless in most cases.
>> That only can be useful for memory only hashes.
>> Because for persistent data it's obvious to always use one hash type 32/64.
>
> I don't think it's a hack. It makes sense. Just should be done centrally
> in Linux, not in a specific user.

So, i must add separate patch for xxhash.h?
If yes, may be you can suggest which list must be in copy?
(i can't find any info about maintainers of ./lib/ in MAINTAINERS)

>>
>> > xxhash_t would seem to be a better name.
>> >
>> >> -     u32 checksum;
>> >> +     xxhash checksum;
>> >>       void *addr = kmap_atomic(page);
>> >> -     checksum = jhash2(addr, PAGE_SIZE / 4, 17);
>> >> +#if BITS_PER_LONG == 64
>> >> +     checksum = xxh64(addr, PAGE_SIZE, 0);
>> >> +#else
>> >> +     checksum = xxh32(addr, PAGE_SIZE, 0);
>> >> +#endif
>> >
>> > This should also be generic in xxhash.h
>>
>> This *can* be generic in xxhash.h, when that solution will be used
>> somewhere in the kernel code, not in the KSM only, not?
>
> Yes.

If we decide to patch xxhash.h,
may be that will be better to wrap above if-else by something like:
/*
 * Only for in memory use
 */
xxhash_t xxhash(const void *input, size_t length, uint64_t seed);

>>
>> Because for now i didn't find other places with "big enough" input
>> data, to replace jhash2 with xxhash.
>
> Right, but we may get them.
>
> -Andi
>

Thanks.
-- 
Have a nice day,
Timofey.

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KSM: Replace jhash2 with xxhash
  2017-09-21 21:37       ` Timofey Titovets
@ 2017-09-21 22:06         ` Andi Kleen
  0 siblings, 0 replies; 7+ messages in thread
From: Andi Kleen @ 2017-09-21 22:06 UTC (permalink / raw)
  To: Timofey Titovets; +Cc: linux-mm

On Fri, Sep 22, 2017 at 12:37:25AM +0300, Timofey Titovets wrote:
> With defaults:
> jhash2: ~4.7%
> xxhash64: ~3.3%
> 
> 3.3/4.7 ~= 0.7 -> Profit: ~30%
> 11/18   ~= 0.6 -> Profit: ~40%
> (if i calculate correctly of course)

Sounds good.

Please add all performance information to the changelog.

> 
> >> >> @@ -51,6 +52,12 @@
> >> >>  #define DO_NUMA(x)   do { } while (0)
> >> >>  #endif
> >> >>
> >> >> +#if BITS_PER_LONG == 64
> >> >> +typedef      u64     xxhash;
> >> >> +#else
> >> >> +typedef      u32     xxhash;
> >> >> +#endif
> >> >
> >> > This should be in xxhash.h ?
> >>
> >> This is a "hack", for compile time chose appropriate hash function.
> >> xxhash ported from upstream code,
> >> upstream version don't do that (IMHO), as this useless in most cases.
> >> That only can be useful for memory only hashes.
> >> Because for persistent data it's obvious to always use one hash type 32/64.
> >
> > I don't think it's a hack. It makes sense. Just should be done centrally
> > in Linux, not in a specific user.
> 
> So, i must add separate patch for xxhash.h?

Yes.

> If yes, may be you can suggest which list must be in copy?
> (i can't find any info about maintainers of ./lib/ in MAINTAINERS)

Just copy linux-kernel. It would be all merged together.

> If we decide to patch xxhash.h,
> may be that will be better to wrap above if-else by something like:
> /*
>  * Only for in memory use
>  */
> xxhash_t xxhash(const void *input, size_t length, uint64_t seed);

Yes that's fine.

-Andi

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KSM: Replace jhash2 with xxhash
  2017-09-21  7:45 [PATCH] KSM: Replace jhash2 with xxhash Timofey Titovets
  2017-09-21 15:36 ` Andi Kleen
@ 2017-09-22  8:44 ` Christian Borntraeger
  1 sibling, 0 replies; 7+ messages in thread
From: Christian Borntraeger @ 2017-09-22  8:44 UTC (permalink / raw)
  To: Timofey Titovets, linux-mm, kvm list, Claudio Imbrenda

Can you please CC the kvm list for these patches. There were other patches
floating around that tried to use the crypto API with CRC and Claudio was working
on some refactoring that made the has function arch specific. 


On 09/21/2017 09:45 AM, Timofey Titovets wrote:
> xxhash much faster then jhash,
> ex. for x86_64 host:
> PAGE_SIZE: 4096, loop count: 1048576
> jhash2:   0xacbc7a5b            time: 1907 ms,  th:  2251.9 MiB/s
> xxhash32: 0x570da981            time: 739 ms,   th:  5809.4 MiB/s
> xxhash64: 0xa1fa032ab85bbb62    time: 371 ms,   th: 11556.6 MiB/s
> 
> xxhash64 on x86_32 work with ~ same speed as jhash2.
> xxhash32 on x86_32 work with ~ same speed as for x86_64
> 
> So replace jhash with xxhash,
> and use fastest version for current target ARCH.
> 
> Signed-off-by: Timofey Titovets <nefelim4ag@gmail.com>
> ---
>  mm/Kconfig |  1 +
>  mm/ksm.c   | 25 ++++++++++++++++++-------
>  2 files changed, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 9c4bdddd80c2..252ab266ac23 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -305,6 +305,7 @@ config MMU_NOTIFIER
>  config KSM
>  	bool "Enable KSM for page merging"
>  	depends on MMU
> +	select XXHASH
>  	help
>  	  Enable Kernel Samepage Merging: KSM periodically scans those areas
>  	  of an application's address space that an app has advised may be
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 15dd7415f7b3..e012d9778c18 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -25,7 +25,8 @@
>  #include <linux/pagemap.h>
>  #include <linux/rmap.h>
>  #include <linux/spinlock.h>
> -#include <linux/jhash.h>
> +#include <linux/xxhash.h>
> +#include <linux/bitops.h> /* BITS_PER_LONG */
>  #include <linux/delay.h>
>  #include <linux/kthread.h>
>  #include <linux/wait.h>
> @@ -51,6 +52,12 @@
>  #define DO_NUMA(x)	do { } while (0)
>  #endif
> 
> +#if BITS_PER_LONG == 64
> +typedef	u64	xxhash;
> +#else
> +typedef	u32	xxhash;
> +#endif
> +
>  /*
>   * A few notes about the KSM scanning process,
>   * to make it easier to understand the data structures below:
> @@ -186,7 +193,7 @@ struct rmap_item {
>  	};
>  	struct mm_struct *mm;
>  	unsigned long address;		/* + low bits used for flags below */
> -	unsigned int oldchecksum;	/* when unstable */
> +	xxhash oldchecksum;		/* when unstable */
>  	union {
>  		struct rb_node node;	/* when node of unstable tree */
>  		struct {		/* when listed from stable tree */
> @@ -255,7 +262,7 @@ static unsigned int ksm_thread_pages_to_scan = 100;
>  static unsigned int ksm_thread_sleep_millisecs = 20;
> 
>  /* Checksum of an empty (zeroed) page */
> -static unsigned int zero_checksum __read_mostly;
> +static xxhash zero_checksum __read_mostly;
> 
>  /* Whether to merge empty (zeroed) pages with actual zero pages */
>  static bool ksm_use_zero_pages __read_mostly;
> @@ -982,11 +989,15 @@ static int unmerge_and_remove_all_rmap_items(void)
>  }
>  #endif /* CONFIG_SYSFS */
> 
> -static u32 calc_checksum(struct page *page)
> +static xxhash calc_checksum(struct page *page)
>  {
> -	u32 checksum;
> +	xxhash checksum;
>  	void *addr = kmap_atomic(page);
> -	checksum = jhash2(addr, PAGE_SIZE / 4, 17);
> +#if BITS_PER_LONG == 64
> +	checksum = xxh64(addr, PAGE_SIZE, 0);
> +#else
> +	checksum = xxh32(addr, PAGE_SIZE, 0);
> +#endif
>  	kunmap_atomic(addr);
>  	return checksum;
>  }
> @@ -1994,7 +2005,7 @@ static void cmp_and_merge_page(struct page *page, struct rmap_item *rmap_item)
>  	struct page *tree_page = NULL;
>  	struct stable_node *stable_node;
>  	struct page *kpage;
> -	unsigned int checksum;
> +	xxhash checksum;
>  	int err;
>  	bool max_page_sharing_bypass = false;
> 

--
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>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-09-22  8:44 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-21  7:45 [PATCH] KSM: Replace jhash2 with xxhash Timofey Titovets
2017-09-21 15:36 ` Andi Kleen
2017-09-21 17:35   ` Timofey Titovets
2017-09-21 20:05     ` Andi Kleen
2017-09-21 21:37       ` Timofey Titovets
2017-09-21 22:06         ` Andi Kleen
2017-09-22  8:44 ` Christian Borntraeger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.