Re: [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07.03.24 12:10, Richard Weinberger wrote:
----- Ursprüngliche Mail -----
Von: "David Hildenbrand" <david@xxxxxxxxxx>
But why is that required? What is the target use case? (I did not get
the cover letter in my inbox)

We're running slowly but steadily out of bits, so we better make wise
decisions.

Also, consider: Architectures where the dirty/access bit is not HW
managed could indicate "writable" here although we *will* get a page
fault to set the page dirty/accessed.

I'm currently investigating why a real-time application faces unexpected
page faults. Page faults are usually fatal for real-time work loads because
the latency constraints are no longer met.

Are you concerned about any type of page fault, or are things like a simple remapping of the same page from "read-only to writable" acceptable? ("very minor fault")


So, I wrote a small tool to inspect the memory mappings of a process to find
areas which are not correctly pre-faulted. While doing so I noticed that
there is currently no way to detect CoW mappings.
Exposing the writable property of a PTE seemed like a good start to me.

Is it just about "detection" for debugging purposes or about "fixup" in running applications?

If it's the latter, MADV_POPULATE_WRITE might do what you want (in writable mappings).

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux