[PATCH v2 0/9] mm/ksm: break_ksm() cleanups and fixes

David Hildenbrand posted 9 patches 1 year, 6 months ago
include/linux/mm.h                            |   1 -
include/linux/mm_types.h                      |   3 -
include/linux/pagewalk.h                      |   5 +
mm/gup.c                                      |  55 +---
mm/huge_memory.c                              |   2 +-
mm/ksm.c                                      |  78 +++--
mm/memory.c                                   |   9 +-
mm/pagewalk.c                                 |  27 +-
tools/testing/selftests/vm/Makefile           |   2 +
.../selftests/vm/ksm_functional_tests.c       | 279 ++++++++++++++++++
tools/testing/selftests/vm/ksm_tests.c        |  76 ++++-
tools/testing/selftests/vm/run_vmtests.sh     |   2 +
tools/testing/selftests/vm/vm_util.c          |  10 +
tools/testing/selftests/vm/vm_util.h          |   1 +
14 files changed, 456 insertions(+), 94 deletions(-)
create mode 100644 tools/testing/selftests/vm/ksm_functional_tests.c
[PATCH v2 0/9] mm/ksm: break_ksm() cleanups and fixes
Posted by David Hildenbrand 1 year, 6 months ago
This series cleans up and fixes break_ksm(). In summary, we no longer
use fake write faults to break COW but instead FAULT_FLAG_UNSHARE. Further,
we move away from using follow_page() --- that we can hopefully remove
completely at one point --- and use new walk_page_range_vma() instead.

Fortunately, we can get rid of VM_FAULT_WRITE and FOLL_MIGRATION in common
code now.

Extend the existing ksm tests by an unmerge benchmark, and a some new
unmerge tests.

Add a selftest to measure MADV_UNMERGEABLE performance. In my setup
(AMD Ryzen 9 3900X), running the KSM selftest to test unmerge performance
on 2 GiB (taskset 0x8 ./ksm_tests -D -s 2048), this results in a
performance degradation of ~6% -- 7% (old: ~5250 MiB/s, new: ~4900 MiB/s).
I don't think we particularly care for now, but it's good to be aware
of the implication.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Peter Xu <peterx@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: John Hubbard <jhubbard@nvidia.com>

v1 -> v2:
* "selftests/vm: add KSM unmerge tests"
 -> Add new unmerge tests
* "mm/ksm: fix KSM COW breaking with userfaultfd-wp via FAULT_FLAG_UNSHARE"
 -> Simplify patch description now that we have a selftest
* "mm/pagewalk: don't trigger test_walk() in walk_page_vma()"
 -> Added
* "mm/pagewalk: add walk_page_range_vma()"
 -> Don't call test_walk()
* "mm/ksm: convert break_ksm() to use walk_page_range_vma()"
 -> Simplify and fix missing unlock, fix missing "static"

David Hildenbrand (9):
  selftests/vm: add test to measure MADV_UNMERGEABLE performance
  mm/ksm: simplify break_ksm() to not rely on VM_FAULT_WRITE
  mm: remove VM_FAULT_WRITE
  selftests/vm: add KSM unmerge tests
  mm/ksm: fix KSM COW breaking with userfaultfd-wp via
    FAULT_FLAG_UNSHARE
  mm/pagewalk: don't trigger test_walk() in walk_page_vma()
  mm/pagewalk: add walk_page_range_vma()
  mm/ksm: convert break_ksm() to use walk_page_range_vma()
  mm/gup: remove FOLL_MIGRATION

 include/linux/mm.h                            |   1 -
 include/linux/mm_types.h                      |   3 -
 include/linux/pagewalk.h                      |   5 +
 mm/gup.c                                      |  55 +---
 mm/huge_memory.c                              |   2 +-
 mm/ksm.c                                      |  78 +++--
 mm/memory.c                                   |   9 +-
 mm/pagewalk.c                                 |  27 +-
 tools/testing/selftests/vm/Makefile           |   2 +
 .../selftests/vm/ksm_functional_tests.c       | 279 ++++++++++++++++++
 tools/testing/selftests/vm/ksm_tests.c        |  76 ++++-
 tools/testing/selftests/vm/run_vmtests.sh     |   2 +
 tools/testing/selftests/vm/vm_util.c          |  10 +
 tools/testing/selftests/vm/vm_util.h          |   1 +
 14 files changed, 456 insertions(+), 94 deletions(-)
 create mode 100644 tools/testing/selftests/vm/ksm_functional_tests.c


base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
-- 
2.37.3
Re: [PATCH v2 0/9] mm/ksm: break_ksm() cleanups and fixes
Posted by Andrew Morton 1 year, 6 months ago
On Fri, 21 Oct 2022 12:11:32 +0200 David Hildenbrand <david@redhat.com> wrote:

> This series cleans up and fixes break_ksm().

Quite a lot of fixups were needed merging this.  I guess you couldn't
develop against mm-unstable because the v1 series was already in there.

For this reason I'll henceforth be more inclined to drop serieses when
I know a full resend is coming out.

So please do let me know when a full resend is coming out.  Or, of
course, send little fixes against the current version.
Re: [PATCH v2 0/9] mm/ksm: break_ksm() cleanups and fixes
Posted by David Hildenbrand 1 year, 6 months ago
On 21.10.22 21:57, Andrew Morton wrote:
> On Fri, 21 Oct 2022 12:11:32 +0200 David Hildenbrand <david@redhat.com> wrote:
> 
>> This series cleans up and fixes break_ksm().
> 
> Quite a lot of fixups were needed merging this.  I guess you couldn't
> develop against mm-unstable because the v1 series was already in there.

Nowadays, I tend to send against mm-stable (I remember that was the 
suggestion). Usually it works because there are no conflicts -- this 
time there are probably quite some kvm unit test conflicts.

Feel free to ask me next time to rebase on XYZ so I can make you life 
easier ;)

> 
> For this reason I'll henceforth be more inclined to drop serieses when
> I know a full resend is coming out.

Yes, good idea. While the fixup-patch process works for small 
adjustments, it's not a good fit for bigger changes, especially once 
involving new patches.

> 
> So please do let me know when a full resend is coming out. 

Will do; I kind-of did that [1] but I should have been more clear 
("Please drop the current series, I'll send a new version.").

> Or, of
> course, send little fixes against the current version.

I prefer a full resend when there are bigger changes that involve 
modifications to multiple patches ... which also makes life easier for 
reviewers.


[1] 
https://lore.kernel.org/all/87104912-6615-4917-eae1-6ae0a80677e1@redhat.com/T/#u

-- 
Thanks,

David / dhildenb