From: Timofey Titovets <nefelim4ag@gmail.com> To: linux-mm@kvack.org Cc: Timofey Titovets <nefelim4ag@gmail.com>, Andrea Arcangeli <aarcange@redhat.com>, kvm@vger.kernel.org, leesioh <solee@os.korea.ac.kr> Subject: [PATCH V6 0/2 RESEND] KSM replace hash algo with faster hash Date: Wed, 7 Feb 2018 13:22:22 +0300 [thread overview] Message-ID: <20180207102224.28016-1-nefelim4ag@gmail.com> (raw) Currently used jhash are slow enough and replace it allow as to make KSM less cpu hungry. About speed (in kernel): ksm: crc32c hash() 12081 MB/s ksm: xxh64 hash() 8770 MB/s ksm: xxh32 hash() 4529 MB/s ksm: jhash2 hash() 1569 MB/s By sioh Lee tests (copy from other mail): Test platform: openstack cloud platform (NEWTON version) Experiment node: openstack based cloud compute node (CPU: xeon E5-2620 v3, memory 64gb) VM: (2 VCPU, RAM 4GB, DISK 20GB) * 4 Linux kernel: 4.14 (latest version) KSM setup - sleep_millisecs: 200ms, pages_to_scan: 200 Experiment process Firstly, we turn off KSM and launch 4 VMs. Then we turn on the KSM and measure the checksum computation time until full_scans become two. The experimental results (the experimental value is the average of the measured values) crc32c_intel: 1084.10ns crc32c (no hardware acceleration): 7012.51ns xxhash32: 2227.75ns xxhash64: 1413.16ns jhash2: 5128.30ns In summary, the result shows that crc32c_intel has advantages over all of the hash function used in the experiment. (decreased by 84.54% compared to crc32c, 78.86% compared to jhash2, 51.33% xxhash32, 23.28% compared to xxhash64) the results are similar to those of Timofey. So: - Fisrt patch implement compile time pickup of fastest implementation of xxhash for target platform. - Second implement logic in ksm, what test speed of hashes and pickup fastest hash Thanks. CC: Andrea Arcangeli <aarcange@redhat.com> CC: linux-mm@kvack.org CC: kvm@vger.kernel.org CC: leesioh <solee@os.korea.ac.kr> Timofey Titovets (2): xxHash: create arch dependent 32/64-bit xxhash() ksm: replace jhash2 with faster hash include/linux/xxhash.h | 23 +++++++++++++ mm/Kconfig | 2 ++ mm/ksm.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 114 insertions(+), 4 deletions(-) -- 2.14.1
WARNING: multiple messages have this Message-ID (diff)
From: Timofey Titovets <nefelim4ag@gmail.com> To: linux-mm@kvack.org Cc: Timofey Titovets <nefelim4ag@gmail.com>, Andrea Arcangeli <aarcange@redhat.com>, kvm@vger.kernel.org, leesioh <solee@os.korea.ac.kr> Subject: [PATCH V6 0/2 RESEND] KSM replace hash algo with faster hash Date: Wed, 7 Feb 2018 13:22:22 +0300 [thread overview] Message-ID: <20180207102224.28016-1-nefelim4ag@gmail.com> (raw) Currently used jhash are slow enough and replace it allow as to make KSM less cpu hungry. About speed (in kernel): ksm: crc32c hash() 12081 MB/s ksm: xxh64 hash() 8770 MB/s ksm: xxh32 hash() 4529 MB/s ksm: jhash2 hash() 1569 MB/s By sioh Lee tests (copy from other mail): Test platform: openstack cloud platform (NEWTON version) Experiment node: openstack based cloud compute node (CPU: xeon E5-2620 v3, memory 64gb) VM: (2 VCPU, RAM 4GB, DISK 20GB) * 4 Linux kernel: 4.14 (latest version) KSM setup - sleep_millisecs: 200ms, pages_to_scan: 200 Experiment process Firstly, we turn off KSM and launch 4 VMs. Then we turn on the KSM and measure the checksum computation time until full_scans become two. The experimental results (the experimental value is the average of the measured values) crc32c_intel: 1084.10ns crc32c (no hardware acceleration): 7012.51ns xxhash32: 2227.75ns xxhash64: 1413.16ns jhash2: 5128.30ns In summary, the result shows that crc32c_intel has advantages over all of the hash function used in the experiment. (decreased by 84.54% compared to crc32c, 78.86% compared to jhash2, 51.33% xxhash32, 23.28% compared to xxhash64) the results are similar to those of Timofey. So: - Fisrt patch implement compile time pickup of fastest implementation of xxhash for target platform. - Second implement logic in ksm, what test speed of hashes and pickup fastest hash Thanks. CC: Andrea Arcangeli <aarcange@redhat.com> CC: linux-mm@kvack.org CC: kvm@vger.kernel.org CC: leesioh <solee@os.korea.ac.kr> Timofey Titovets (2): xxHash: create arch dependent 32/64-bit xxhash() ksm: replace jhash2 with faster hash include/linux/xxhash.h | 23 +++++++++++++ mm/Kconfig | 2 ++ mm/ksm.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 114 insertions(+), 4 deletions(-) -- 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>
next reply other threads:[~2018-02-07 10:22 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-02-07 10:22 Timofey Titovets [this message] 2018-02-07 10:22 ` [PATCH V6 0/2 RESEND] KSM replace hash algo with faster hash Timofey Titovets 2018-02-07 10:22 ` [PATCH V6 1/2 RESEND] xxHash: create arch dependent 32/64-bit xxhash() Timofey Titovets 2018-02-07 10:22 ` Timofey Titovets 2018-02-07 10:22 ` [PATCH V6 2/2 RESEND] ksm: replace jhash2 with faster hash Timofey Titovets 2018-02-07 10:22 ` Timofey Titovets 2018-04-18 19:32 [PATCH V6 0/2 RESEND] KSM replace hash algo " Timofey Titovets
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=20180207102224.28016-1-nefelim4ag@gmail.com \ --to=nefelim4ag@gmail.com \ --cc=aarcange@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=solee@os.korea.ac.kr \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.