mbox series

[v2,0/5] mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page tables

Message ID 20210419135443.12822-1-david@redhat.com (mailing list archive)
Headers show
Series mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page tables | expand

Message

David Hildenbrand April 19, 2021, 1:54 p.m. UTC
Excessive details on MADV_POPULATE_(READ|WRITE) can be found in patch #2.

v1 -> v2:
- "mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page
   tables"
-- Renamed patch/series to match what's happening -- prefault page tables
-- Clarified MADV_POPULATE_READ semantics on file holes and that we might
   want fallocate().
-- Updated/clarified description
-- Dropped -EINVAL and -EBUSY checks
-- Added a comment regarding FOLL_TOUCH and why we don't care that
   pages will get set dirty when triggering write-faults for now.
-- Reran and extended performance measurements by more fallocate()
   combinations

RFCv2 -> v1
- "mm: fix variable name in declaration of populate_vma_page_range()"
-- Added
- "mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault ..."
-- Fix detection of memory holes when we have to re-lookup the VMA
-- Return -EHWPOISON to user space when we hit HW poisoned pages
-- Make variable names in definition and declaration consistent
- "MAINTAINERS: add tools/testing/selftests/vm/ to MEMORY MANAGEMENT"
-- Added
- "selftests/vm: add protection_keys_32 / protection_keys_64 to gitignore"
-- Added
- "selftests/vm: add test for MADV_POPULATE_(READ|WRITE)"
-- Added

RFC -> RFCv2:
- Fix re-locking (-> set "locked = 1;")
- Don't mimic MAP_POPULATE semantics:
--> Explicit READ/WRITE request instead of selecting it automatically,
    which makes it more generic and better suited for some use cases (e.g., we
    usually want to prefault shmem writable)
--> Require proper access permissions
- Introduce and use faultin_vma_page_range()
--> Properly handle HWPOISON pages (FOLL_HWPOISON)
--> Require proper access permissions (!FOLL_FORCE)
- Let faultin_vma_page_range() check for compatible mappings/permissions
- Extend patch description and add some performance numbers


David Hildenbrand (5):
  mm: make variable names for populate_vma_page_range() consistent
  mm/madvise: introduce MADV_POPULATE_(READ|WRITE) to prefault page
    tables
  MAINTAINERS: add tools/testing/selftests/vm/ to MEMORY MANAGEMENT
  selftests/vm: add protection_keys_32 / protection_keys_64 to gitignore
  selftests/vm: add test for MADV_POPULATE_(READ|WRITE)

 MAINTAINERS                                |   1 +
 arch/alpha/include/uapi/asm/mman.h         |   3 +
 arch/mips/include/uapi/asm/mman.h          |   3 +
 arch/parisc/include/uapi/asm/mman.h        |   3 +
 arch/xtensa/include/uapi/asm/mman.h        |   3 +
 include/uapi/asm-generic/mman-common.h     |   3 +
 mm/gup.c                                   |  58 ++++
 mm/internal.h                              |   5 +-
 mm/madvise.c                               |  66 ++++
 tools/testing/selftests/vm/.gitignore      |   3 +
 tools/testing/selftests/vm/Makefile        |   1 +
 tools/testing/selftests/vm/madv_populate.c | 342 +++++++++++++++++++++
 tools/testing/selftests/vm/run_vmtests.sh  |  16 +
 13 files changed, 506 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/vm/madv_populate.c

Comments

Andrew Morton May 10, 2021, 4:21 a.m. UTC | #1
On Mon, 19 Apr 2021 15:54:38 +0200 David Hildenbrand <david@redhat.com> wrote:

> Excessive details on MADV_POPULATE_(READ|WRITE) can be found in patch #2.

I grabbed the series, but some additional review would help things
along here..

Did patch #2 actually make it to linux-mm?  It's missing from my
archive. 
https://lkml.kernel.org/r/20210419135443.12822-3-david@redhat.com lands
on the linux-api@vger copy.
David Hildenbrand May 10, 2021, 2:52 p.m. UTC | #2
On 10.05.21 06:21, Andrew Morton wrote:
> On Mon, 19 Apr 2021 15:54:38 +0200 David Hildenbrand <david@redhat.com> wrote:
> 
>> Excessive details on MADV_POPULATE_(READ|WRITE) can be found in patch #2.
> 
> I grabbed the series, but some additional review would help things
> along here..

Thanks -- indeed, while there have been some comments to previous 
versions that improved the series as a whole, there are no explicit acks 
or rbs. Fortunately, we still have some time until the next merge window 
opens :)

> 
> Did patch #2 actually make it to linux-mm?  It's missing from my
> archive.

Ehm, good point. I punch out everything via " git send-email  --to 
linux-kernel@vger.kernel.org  --cc "linux-mm@kvack.org" ..." and don't 
remember any bounces.

Doesn't seem to appear on linux-mm:

https://lore.kernel.org/linux-mm/20210419135443.12822-1-david@redhat.com/

But it did make it to lkml as well:

https://lore.kernel.org/lkml/20210419135443.12822-3-david@redhat.com/

> https://lkml.kernel.org/r/20210419135443.12822-3-david@redhat.com lands
> on the linux-api@vger copy.

Weird, looks like linux-mm is swallowing mails.

I can just resend the series, thoughts?
Andrew Morton May 11, 2021, 12:59 a.m. UTC | #3
On Mon, 10 May 2021 16:52:33 +0200 David Hildenbrand <david@redhat.com> wrote:

> I can just resend the series, thoughts?

Sure, that makes it easier on folks.