| Message ID | 20220726161854.276359-1-usama.anjum@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add process_memwatch syscall | expand |
On 7/26/22 9:18 PM, Muhammad Usama Anjum wrote: > Hello, > > This patch series implements a new syscall, process_memwatch. Currently, > only the support to watch soft-dirty PTE bit is added. This syscall is > generic to watch the memory of the process. There is enough room to add > more operations like this to watch memory in the future. > > Soft-dirty PTE bit of the memory pages can be viewed by using pagemap > procfs file. The soft-dirty PTE bit for the memory in a process can be > cleared by writing to the clear_refs file. This series adds features that > weren't possible through the Proc FS interface. > - There is no atomic get soft-dirty PTE bit status and clear operation > possible. > - The soft-dirty PTE bit of only a part of memory cannot be cleared. > > Historically, soft-dirty PTE bit tracking has been used in the CRIU > project. The Proc FS interface is enough for that as I think the process > is frozen. We have the use case where we need to track the soft-dirty > PTE bit for running processes. We need this tracking and clear mechanism > of a region of memory while the process is running to emulate the > getWriteWatch() syscall of Windows. This syscall is used by games to keep > track of dirty pages and keep processing only the dirty pages. This > syscall can be used by the CRIU project and other applications which > require soft-dirty PTE bit information. > > As in the current kernel there is no way to clear a part of memory (instead > of clearing the Soft-Dirty bits for the entire processi) and get+clear > operation cannot be performed atomically, there are other methods to mimic > this information entirely in userspace with poor performance: > - The mprotect syscall and SIGSEGV handler for bookkeeping > - The userfaultfd syscall with the handler for bookkeeping > > long process_memwatch(int pidfd, unsigned long start, int len, > unsigned int flags, void *vec, int vec_len); Any thoughts? > > This syscall can be used by the CRIU project and other applications which > require soft-dirty PTE bit information. The following operations are > supported in this syscall: > - Get the pages that are soft-dirty. > - Clear the pages which are soft-dirty. > - The optional flag to ignore the VM_SOFTDIRTY and only track per page > soft-dirty PTE bit > > There are two decisions which have been taken about how to get the output > from the syscall. > - Return offsets of the pages from the start in the vec > - Stop execution when vec is filled with dirty pages > These two arguments doesn't follow the mincore() philosophy where the > output array corresponds to the address range in one to one fashion, hence > the output buffer length isn't passed and only a flag is set if the page > is present. This makes mincore() easy to use with less control. We are > passing the size of the output array and putting return data consecutively > which is offset of dirty pages from the start. The user can convert these > offsets back into the dirty page addresses easily. Suppose, the user want > to get first 10 dirty pages from a total memory of 100 pages. He'll > allocate output buffer of size 10 and process_memwatch() syscall will > abort after finding the 10 pages. This behaviour is needed to support > Windows' getWriteWatch(). The behaviour like mincore() can be achieved by > passing output buffer of 100 size. This interface can be used for any > desired behaviour. > > Regards, > Muhammad Usama Anjum > > Muhammad Usama Anjum (5): > fs/proc/task_mmu: make functions global to be used in other files > mm: Implement process_memwatch syscall > mm: wire up process_memwatch syscall for x86 > selftests: vm: add process_memwatch syscall tests > mm: add process_memwatch syscall documentation > > Documentation/admin-guide/mm/soft-dirty.rst | 48 +- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > fs/proc/task_mmu.c | 84 +-- > include/linux/mm_inline.h | 99 +++ > include/linux/syscalls.h | 3 +- > include/uapi/asm-generic/unistd.h | 5 +- > include/uapi/linux/memwatch.h | 12 + > kernel/sys_ni.c | 1 + > mm/Makefile | 2 +- > mm/memwatch.c | 285 ++++++++ > tools/include/uapi/asm-generic/unistd.h | 5 +- > .../arch/x86/entry/syscalls/syscall_64.tbl | 1 + > tools/testing/selftests/vm/.gitignore | 1 + > tools/testing/selftests/vm/Makefile | 2 + > tools/testing/selftests/vm/memwatch_test.c | 635 ++++++++++++++++++ > 16 files changed, 1098 insertions(+), 87 deletions(-) > create mode 100644 include/uapi/linux/memwatch.h > create mode 100644 mm/memwatch.c > create mode 100644 tools/testing/selftests/vm/memwatch_test.c >
On 26.07.22 18:18, Muhammad Usama Anjum wrote: > Hello, Hi, > > This patch series implements a new syscall, process_memwatch. Currently, > only the support to watch soft-dirty PTE bit is added. This syscall is > generic to watch the memory of the process. There is enough room to add > more operations like this to watch memory in the future. > > Soft-dirty PTE bit of the memory pages can be viewed by using pagemap > procfs file. The soft-dirty PTE bit for the memory in a process can be > cleared by writing to the clear_refs file. This series adds features that > weren't possible through the Proc FS interface. > - There is no atomic get soft-dirty PTE bit status and clear operation > possible. Such an interface might be easy to add, no? > - The soft-dirty PTE bit of only a part of memory cannot be cleared. Same. So I'm curious why we need a new syscall for that. > > Historically, soft-dirty PTE bit tracking has been used in the CRIU > project. The Proc FS interface is enough for that as I think the process > is frozen. We have the use case where we need to track the soft-dirty > PTE bit for running processes. We need this tracking and clear mechanism > of a region of memory while the process is running to emulate the > getWriteWatch() syscall of Windows. This syscall is used by games to keep > track of dirty pages and keep processing only the dirty pages. This > syscall can be used by the CRIU project and other applications which > require soft-dirty PTE bit information. > > As in the current kernel there is no way to clear a part of memory (instead > of clearing the Soft-Dirty bits for the entire processi) and get+clear > operation cannot be performed atomically, there are other methods to mimic > this information entirely in userspace with poor performance: > - The mprotect syscall and SIGSEGV handler for bookkeeping > - The userfaultfd syscall with the handler for bookkeeping You write "poor performance". Did you actually implement a prototype using userfaultfd-wp? Can you share numbers for comparison? Adding an new syscall just for handling a corner case feature (soft-dirty, which we all love, of course) needs good justification. > > long process_memwatch(int pidfd, unsigned long start, int len, > unsigned int flags, void *vec, int vec_len); > > This syscall can be used by the CRIU project and other applications which > require soft-dirty PTE bit information. The following operations are > supported in this syscall: > - Get the pages that are soft-dirty. > - Clear the pages which are soft-dirty. > - The optional flag to ignore the VM_SOFTDIRTY and only track per page > soft-dirty PTE bit Huh, why? VM_SOFTDIRTY is an internal implementation detail and should remain such. VM_SOFTDIRTY translates to "all pages in this VMA are soft-dirty".
On 7/26/22 18:18, Muhammad Usama Anjum wrote: > Hello, > > This patch series implements a new syscall, process_memwatch. Currently, > only the support to watch soft-dirty PTE bit is added. This syscall is > generic to watch the memory of the process. There is enough room to add > more operations like this to watch memory in the future. > > Soft-dirty PTE bit of the memory pages can be viewed by using pagemap > procfs file. The soft-dirty PTE bit for the memory in a process can be > cleared by writing to the clear_refs file. This series adds features that > weren't possible through the Proc FS interface. > - There is no atomic get soft-dirty PTE bit status and clear operation > possible. > - The soft-dirty PTE bit of only a part of memory cannot be cleared. > > Historically, soft-dirty PTE bit tracking has been used in the CRIU > project. The Proc FS interface is enough for that as I think the process > is frozen. We have the use case where we need to track the soft-dirty > PTE bit for running processes. We need this tracking and clear mechanism > of a region of memory while the process is running to emulate the > getWriteWatch() syscall of Windows. This syscall is used by games to keep > track of dirty pages and keep processing only the dirty pages. This > syscall can be used by the CRIU project and other applications which > require soft-dirty PTE bit information. > > As in the current kernel there is no way to clear a part of memory (instead > of clearing the Soft-Dirty bits for the entire processi) and get+clear > operation cannot be performed atomically, there are other methods to mimic > this information entirely in userspace with poor performance: > - The mprotect syscall and SIGSEGV handler for bookkeeping > - The userfaultfd syscall with the handler for bookkeeping > > long process_memwatch(int pidfd, unsigned long start, int len, > unsigned int flags, void *vec, int vec_len); > > This syscall can be used by the CRIU project and other applications which > require soft-dirty PTE bit information. The following operations are > supported in this syscall: > - Get the pages that are soft-dirty. > - Clear the pages which are soft-dirty. > - The optional flag to ignore the VM_SOFTDIRTY and only track per page > soft-dirty PTE bit > Why can it not be done as a IOCTL? > There are two decisions which have been taken about how to get the output > from the syscall. > - Return offsets of the pages from the start in the vec > - Stop execution when vec is filled with dirty pages > These two arguments doesn't follow the mincore() philosophy where the > output array corresponds to the address range in one to one fashion, hence > the output buffer length isn't passed and only a flag is set if the page > is present. This makes mincore() easy to use with less control. We are > passing the size of the output array and putting return data consecutively > which is offset of dirty pages from the start. The user can convert these > offsets back into the dirty page addresses easily. Suppose, the user want > to get first 10 dirty pages from a total memory of 100 pages. He'll > allocate output buffer of size 10 and process_memwatch() syscall will > abort after finding the 10 pages. This behaviour is needed to support > Windows' getWriteWatch(). The behaviour like mincore() can be achieved by > passing output buffer of 100 size. This interface can be used for any > desired behaviour. > > Regards, > Muhammad Usama Anjum > > Muhammad Usama Anjum (5): > fs/proc/task_mmu: make functions global to be used in other files > mm: Implement process_memwatch syscall > mm: wire up process_memwatch syscall for x86 > selftests: vm: add process_memwatch syscall tests > mm: add process_memwatch syscall documentation > > Documentation/admin-guide/mm/soft-dirty.rst | 48 +- > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > fs/proc/task_mmu.c | 84 +-- > include/linux/mm_inline.h | 99 +++ > include/linux/syscalls.h | 3 +- > include/uapi/asm-generic/unistd.h | 5 +- > include/uapi/linux/memwatch.h | 12 + > kernel/sys_ni.c | 1 + > mm/Makefile | 2 +- > mm/memwatch.c | 285 ++++++++ > tools/include/uapi/asm-generic/unistd.h | 5 +- > .../arch/x86/entry/syscalls/syscall_64.tbl | 1 + > tools/testing/selftests/vm/.gitignore | 1 + > tools/testing/selftests/vm/Makefile | 2 + > tools/testing/selftests/vm/memwatch_test.c | 635 ++++++++++++++++++ > 16 files changed, 1098 insertions(+), 87 deletions(-) > create mode 100644 include/uapi/linux/memwatch.h > create mode 100644 mm/memwatch.c > create mode 100644 tools/testing/selftests/vm/memwatch_test.c >
Hello, Thank you for reviewing and commenting. On 8/10/22 2:03 PM, David Hildenbrand wrote: > On 26.07.22 18:18, Muhammad Usama Anjum wrote: >> Hello, > > Hi, > >> >> This patch series implements a new syscall, process_memwatch. Currently, >> only the support to watch soft-dirty PTE bit is added. This syscall is >> generic to watch the memory of the process. There is enough room to add >> more operations like this to watch memory in the future. >> >> Soft-dirty PTE bit of the memory pages can be viewed by using pagemap >> procfs file. The soft-dirty PTE bit for the memory in a process can be >> cleared by writing to the clear_refs file. This series adds features that >> weren't possible through the Proc FS interface. >> - There is no atomic get soft-dirty PTE bit status and clear operation >> possible. > > Such an interface might be easy to add, no? Are you referring to ioctl? I think this syscall can be used in future for adding other operations like soft-dirty. This is why syscall has been added. If community doesn't agree, I can translate this syscall to the ioctl same as it is. > >> - The soft-dirty PTE bit of only a part of memory cannot be cleared. > > Same. > > So I'm curious why we need a new syscall for that. > >> >> Historically, soft-dirty PTE bit tracking has been used in the CRIU >> project. The Proc FS interface is enough for that as I think the process >> is frozen. We have the use case where we need to track the soft-dirty >> PTE bit for running processes. We need this tracking and clear mechanism >> of a region of memory while the process is running to emulate the >> getWriteWatch() syscall of Windows. This syscall is used by games to keep >> track of dirty pages and keep processing only the dirty pages. This >> syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. >> >> As in the current kernel there is no way to clear a part of memory (instead >> of clearing the Soft-Dirty bits for the entire processi) and get+clear >> operation cannot be performed atomically, there are other methods to mimic >> this information entirely in userspace with poor performance: >> - The mprotect syscall and SIGSEGV handler for bookkeeping >> - The userfaultfd syscall with the handler for bookkeeping > > You write "poor performance". Did you actually implement a prototype > using userfaultfd-wp? Can you share numbers for comparison? > > Adding an new syscall just for handling a corner case feature > (soft-dirty, which we all love, of course) needs good justification. The cycles are given in thousands. 60 means 60k cycles here which have been measured with rdtsc(). | | Region size in Pages | 1 | 10 | 100 | 1000 | 10000 | |---|----------------------|------|------|-------|-------|--------| | 1 | MEMWATCH | 7 | 58 | 281 | 1178 | 17563 | | 2 | MEMWATCH Perf | 4 | 23 | 107 | 1331 | 8924 | | 3 | USERFAULTFD | 5405 | 6550 | 10387 | 55708 | 621522 | | 4 | MPROTECT_SEGV | 35 | 611 | 1060 | 6646 | 60149 | 1. MEMWATCH --> process_memwatch considering VM_SOFTDIRT (splitting is possible) 2. MEMWATCH Perf --> process_memwatch without considering VM_SOFTDIRTY 3. Userafaultfd --> userfaultfd with handling is userspace 4. Mprotect_segv --> mprotect and signal handler in userspace Note: Implementation of mprotect_segv is very similar to userfaultfd. In both of these, the signal/fault is being handled in the userspace. In mprotect_segv, the memory region is write-protected through mprotect and SEGV signal is received when something is written to this region. This signal's handler is where we do calculations about soft dirty pages. Mprotect_segv mechanism must be lighter than userfaultfd inside kernel. My benchmark application is purely single threaded to keep effort to a minimum until we decide to spend more time. It has been written to measure the time taken in a serial execution of these statements without locks. If the multi-threaded application is used and randomization is introduced, it should affect `MPROTECT_SEGV` and `userfaultd` implementations more than memwatch. But in this particular setting, memwatch and mprotect_segv perform closely. > >> >> long process_memwatch(int pidfd, unsigned long start, int len, >> unsigned int flags, void *vec, int vec_len); >> >> This syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. The following operations are >> supported in this syscall: >> - Get the pages that are soft-dirty. >> - Clear the pages which are soft-dirty. >> - The optional flag to ignore the VM_SOFTDIRTY and only track per page >> soft-dirty PTE bit > > Huh, why? VM_SOFTDIRTY is an internal implementation detail and should > remain such. > > VM_SOFTDIRTY translates to "all pages in this VMA are soft-dirty". Clearing soft-dirty bit for a range of memory may result in splitting the VMA. Soft-dirty bit of the per page need to be cleared. The VM_SOFTDIRTY flag from this splitted VMA need to be cleared. The kernel may decide to merge this splitted VMA back. Please note that kernel doesn't take into account the VM_SOFTDIRTY flag of the VMAs when it decides to merge the VMAs. This not only gives performance hit, but also the non-dirty pages of the whole VMA start to appear as dirty again after the VMA merging. To avoid this penalty, MEMWATCH_SD_NO_REUSED_REGIONS flag has been added to ignore the VM_SOFTDIRTY and just rely on the soft-dirty bit present on the per page. The user is aware about the constraint that the new regions will not be found dirty if this flag is specified. >
On 8/10/22 2:22 PM, Peter.Enderborg@sony.com wrote: > On 7/26/22 18:18, Muhammad Usama Anjum wrote: >> Hello, >> >> This patch series implements a new syscall, process_memwatch. Currently, >> only the support to watch soft-dirty PTE bit is added. This syscall is >> generic to watch the memory of the process. There is enough room to add >> more operations like this to watch memory in the future. >> >> Soft-dirty PTE bit of the memory pages can be viewed by using pagemap >> procfs file. The soft-dirty PTE bit for the memory in a process can be >> cleared by writing to the clear_refs file. This series adds features that >> weren't possible through the Proc FS interface. >> - There is no atomic get soft-dirty PTE bit status and clear operation >> possible. >> - The soft-dirty PTE bit of only a part of memory cannot be cleared. >> >> Historically, soft-dirty PTE bit tracking has been used in the CRIU >> project. The Proc FS interface is enough for that as I think the process >> is frozen. We have the use case where we need to track the soft-dirty >> PTE bit for running processes. We need this tracking and clear mechanism >> of a region of memory while the process is running to emulate the >> getWriteWatch() syscall of Windows. This syscall is used by games to keep >> track of dirty pages and keep processing only the dirty pages. This >> syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. >> >> As in the current kernel there is no way to clear a part of memory (instead >> of clearing the Soft-Dirty bits for the entire processi) and get+clear >> operation cannot be performed atomically, there are other methods to mimic >> this information entirely in userspace with poor performance: >> - The mprotect syscall and SIGSEGV handler for bookkeeping >> - The userfaultfd syscall with the handler for bookkeeping >> >> long process_memwatch(int pidfd, unsigned long start, int len, >> unsigned int flags, void *vec, int vec_len); >> >> This syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. The following operations are >> supported in this syscall: >> - Get the pages that are soft-dirty. >> - Clear the pages which are soft-dirty. >> - The optional flag to ignore the VM_SOFTDIRTY and only track per page >> soft-dirty PTE bit >> > > Why can it not be done as a IOCTL? It can be done as ioctl. I think this syscall can be used in future for adding other operations like soft-dirty. This is why syscall has been added.
"Peter.Enderborg@sony.com" <Peter.Enderborg@sony.com> writes: >> >> This syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. The following operations are >> supported in this syscall: >> - Get the pages that are soft-dirty. >> - Clear the pages which are soft-dirty. >> - The optional flag to ignore the VM_SOFTDIRTY and only track per page >> soft-dirty PTE bit >> Hi Peter, (For context, I wrote a previous version of this patch and have been working with Usama on the current patch). > Why can it not be done as a IOCTL? Considering an ioctl is basically a namespaced syscall with extra-steps, surely we can do it :) There are a few reasons we haven't, though: 1) ioctl auditing/controling is much harder than syscall 2) There is a concern for performance, since this might be executed frequently by windows applications running over wine. There is an extra cost with unnecessary copy_[from/to]_user that we wanted to avoid, even though we haven't measured. 3) I originally wrote this at the time process_memadvise was merged. I felt it fits the same kind of interface exposed by process_memadvise/process_mrelease, recently merged. 4) Not obvious whether the ioctl would be against pagemap/clear_refs. Neither file name describes both input and output semantics. Obviously, all of those reasons can be worked around, and we can turn this into an ioctl. Thanks,
David Hildenbrand <david@redhat.com> writes: > On 26.07.22 18:18, Muhammad Usama Anjum wrote: >> Hello, > > Hi, > >> >> This patch series implements a new syscall, process_memwatch. Currently, >> only the support to watch soft-dirty PTE bit is added. This syscall is >> generic to watch the memory of the process. There is enough room to add >> more operations like this to watch memory in the future. >> >> Soft-dirty PTE bit of the memory pages can be viewed by using pagemap >> procfs file. The soft-dirty PTE bit for the memory in a process can be >> cleared by writing to the clear_refs file. This series adds features that >> weren't possible through the Proc FS interface. >> - There is no atomic get soft-dirty PTE bit status and clear operation >> possible. > > Such an interface might be easy to add, no? > >> - The soft-dirty PTE bit of only a part of memory cannot be cleared. > > Same. > > So I'm curious why we need a new syscall for that. Hi David, Yes, sure. Though it has to be through an ioctl since we need both input and output semantics at the same call to keep the atomic semantics. I answered Peter Enderborg about our concerns when turning this into an ioctl. But they are possible to overcome. >> project. The Proc FS interface is enough for that as I think the process >> is frozen. We have the use case where we need to track the soft-dirty >> PTE bit for running processes. We need this tracking and clear mechanism >> of a region of memory while the process is running to emulate the >> getWriteWatch() syscall of Windows. This syscall is used by games to keep >> track of dirty pages and keep processing only the dirty pages. This >> syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. >> >> As in the current kernel there is no way to clear a part of memory (instead >> of clearing the Soft-Dirty bits for the entire processi) and get+clear >> operation cannot be performed atomically, there are other methods to mimic >> this information entirely in userspace with poor performance: >> - The mprotect syscall and SIGSEGV handler for bookkeeping >> - The userfaultfd syscall with the handler for bookkeeping > > You write "poor performance". Did you actually implement a prototype > using userfaultfd-wp? Can you share numbers for comparison? Yes, we did. I think Usama can share some numbers. The problem with userfaultfd, as far as I understand, is that it will require a second userspace process to be called in order to handle the annotation that a page was touched, before remapping the page to make it accessible to the originating process, every time a page is touched. This context switch is prohibitively expensive to our use case, where Windows applications might invoke it quite often. Soft-dirty bit instead, allows the page tracking to be done entirely in kernelspace. If I understand correctly, userfaultfd is usefull for VM/container migration, where the cost of the context switch is not a real concern, since there are much bigger costs from the migration itself. Maybe we're missing some feature about userfaultfd that would allow us to avoid the cost, but from our observations we didn't find a way to overcome it. >> long process_memwatch(int pidfd, unsigned long start, int len, >> unsigned int flags, void *vec, int vec_len); >> >> This syscall can be used by the CRIU project and other applications which >> require soft-dirty PTE bit information. The following operations are >> supported in this syscall: >> - Get the pages that are soft-dirty. >> - Clear the pages which are soft-dirty. >> - The optional flag to ignore the VM_SOFTDIRTY and only track per page >> soft-dirty PTE bit > > Huh, why? VM_SOFTDIRTY is an internal implementation detail and should > remain such. > VM_SOFTDIRTY translates to "all pages in this VMA are soft-dirty". That is something very specific about our use case, and we should explain it a bit better. The problem is that VM_SOFTDIRTY modifications introduce the overhead of the mm write lock acquisition, which is very visible in our benchmarks of Windows games running over Wine. Since the main reason for VM_SOFTDIRTY to exist, as far as we understand it, is to track vma remapping, and this is a use case we don't need to worry about when implementing windows semantics, we'd like to be able to avoid this extra overhead, optionally, iff userspace knows it can be done safely. VM_SOFTDIRTY is indeed an internal interface. Which is why we are proposing to expose the feature in terms of tracking VMA reuse. Thanks,
Hello, This patch series implements a new syscall, process_memwatch. Currently, only the support to watch soft-dirty PTE bit is added. This syscall is generic to watch the memory of the process. There is enough room to add more operations like this to watch memory in the future. Soft-dirty PTE bit of the memory pages can be viewed by using pagemap procfs file. The soft-dirty PTE bit for the memory in a process can be cleared by writing to the clear_refs file. This series adds features that weren't possible through the Proc FS interface. - There is no atomic get soft-dirty PTE bit status and clear operation possible. - The soft-dirty PTE bit of only a part of memory cannot be cleared. Historically, soft-dirty PTE bit tracking has been used in the CRIU project. The Proc FS interface is enough for that as I think the process is frozen. We have the use case where we need to track the soft-dirty PTE bit for running processes. We need this tracking and clear mechanism of a region of memory while the process is running to emulate the getWriteWatch() syscall of Windows. This syscall is used by games to keep track of dirty pages and keep processing only the dirty pages. This syscall can be used by the CRIU project and other applications which require soft-dirty PTE bit information. As in the current kernel there is no way to clear a part of memory (instead of clearing the Soft-Dirty bits for the entire processi) and get+clear operation cannot be performed atomically, there are other methods to mimic this information entirely in userspace with poor performance: - The mprotect syscall and SIGSEGV handler for bookkeeping - The userfaultfd syscall with the handler for bookkeeping long process_memwatch(int pidfd, unsigned long start, int len, unsigned int flags, void *vec, int vec_len); This syscall can be used by the CRIU project and other applications which require soft-dirty PTE bit information. The following operations are supported in this syscall: - Get the pages that are soft-dirty. - Clear the pages which are soft-dirty. - The optional flag to ignore the VM_SOFTDIRTY and only track per page soft-dirty PTE bit There are two decisions which have been taken about how to get the output from the syscall. - Return offsets of the pages from the start in the vec - Stop execution when vec is filled with dirty pages These two arguments doesn't follow the mincore() philosophy where the output array corresponds to the address range in one to one fashion, hence the output buffer length isn't passed and only a flag is set if the page is present. This makes mincore() easy to use with less control. We are passing the size of the output array and putting return data consecutively which is offset of dirty pages from the start. The user can convert these offsets back into the dirty page addresses easily. Suppose, the user want to get first 10 dirty pages from a total memory of 100 pages. He'll allocate output buffer of size 10 and process_memwatch() syscall will abort after finding the 10 pages. This behaviour is needed to support Windows' getWriteWatch(). The behaviour like mincore() can be achieved by passing output buffer of 100 size. This interface can be used for any desired behaviour. Regards, Muhammad Usama Anjum Muhammad Usama Anjum (5): fs/proc/task_mmu: make functions global to be used in other files mm: Implement process_memwatch syscall mm: wire up process_memwatch syscall for x86 selftests: vm: add process_memwatch syscall tests mm: add process_memwatch syscall documentation Documentation/admin-guide/mm/soft-dirty.rst | 48 +- arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + fs/proc/task_mmu.c | 84 +-- include/linux/mm_inline.h | 99 +++ include/linux/syscalls.h | 3 +- include/uapi/asm-generic/unistd.h | 5 +- include/uapi/linux/memwatch.h | 12 + kernel/sys_ni.c | 1 + mm/Makefile | 2 +- mm/memwatch.c | 285 ++++++++ tools/include/uapi/asm-generic/unistd.h | 5 +- .../arch/x86/entry/syscalls/syscall_64.tbl | 1 + tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 2 + tools/testing/selftests/vm/memwatch_test.c | 635 ++++++++++++++++++ 16 files changed, 1098 insertions(+), 87 deletions(-) create mode 100644 include/uapi/linux/memwatch.h create mode 100644 mm/memwatch.c create mode 100644 tools/testing/selftests/vm/memwatch_test.c