linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mm <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	upstream+pagemap <upstream+pagemap@sigma-star.at>,
	adobriyan <adobriyan@gmail.com>,
	wangkefeng wang <wangkefeng.wang@huawei.com>,
	ryan roberts <ryan.roberts@arm.com>, hughd <hughd@google.com>,
	peterx <peterx@redhat.com>, avagin <avagin@google.com>,
	lstoakes <lstoakes@gmail.com>, vbabka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	usama anjum <usama.anjum@collabora.com>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable
Date: Thu, 7 Mar 2024 12:59:26 +0100	[thread overview]
Message-ID: <0644814b-869b-4694-bdb1-bab4e6186136@redhat.com> (raw)
In-Reply-To: <1525238492.23321.1709812267495.JavaMail.zimbra@nod.at>

On 07.03.24 12:51, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "David Hildenbrand" <david@redhat.com>
>>> 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")
> 
> Any page fault has to be avoided.
> To give you more background, the real time application runs on Xenomai,
> a real time extension for Linux.
> Xenomai applies already many tweaks to the kernel to trigger pre-faulting of
> memory areas. But sometimes the application does not use the Xenomai API
> correctly or there is an bug in Xenomai it self.
> Currently I'm suspecting the latter.
>   

Thanks for the details!

>>>
>>> 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?
> 
> It's only about debugging. If an application fails a test I want to have
> a tool which tells me what memory mappings are wonky or could cause a fault
> at runtime.

One destructive way to find out in a writable mapping if the page would 
actually get remapped:

a) Read the PFN of a virtual address using pagemap
b) Write to the virtual address using /proc/pid/mem
c) Read the PFN of a virtual address using pagemap to see if it changed

If the application can be paused, you could read+write a single byte, 
turning it non-destructive.

But that would still "hide" the remap-writable-type faults.

> 
> I fully understand that my use case is a corner case and anything but mainline.
> While developing my debug tool I thought that improving the pagemap interface
> might help others too.

I'm fine with this (can be a helpful debugging tool for some other cases 
as well, and IIRC we don't have another interface to introspect this), 
as long as we properly document the corner case that there could still 
be writefaults on some architectures when the page would not be 
accessed/dirty yet.

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-03-07 11:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 23:23 Richard Weinberger
2024-03-06 23:23 ` [PATCH 2/2] [RFC] pagemap.rst: Document write bit Richard Weinberger
2024-03-07 10:52   ` David Hildenbrand
2024-03-07 11:10     ` Richard Weinberger
2024-03-07 11:15       ` David Hildenbrand
2024-03-10 22:14   ` Lorenzo Stoakes
2024-03-07 10:44 ` [PATCH 1/2] [RFC] proc: pagemap: Expose whether a PTE is writable Muhammad Usama Anjum
2024-03-07 10:52 ` David Hildenbrand
2024-03-07 11:10   ` Richard Weinberger
2024-03-07 11:20     ` David Hildenbrand
2024-03-07 11:51       ` Richard Weinberger
2024-03-07 11:59         ` David Hildenbrand [this message]
2024-03-07 12:09           ` David Hildenbrand
2024-03-07 14:42             ` Richard Weinberger
2024-03-10 21:55 ` Lorenzo Stoakes

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=0644814b-869b-4694-bdb1-bab4e6186136@redhat.com \
    --to=david@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@google.com \
    --cc=corbet@lwn.net \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=peterx@redhat.com \
    --cc=richard@nod.at \
    --cc=ryan.roberts@arm.com \
    --cc=upstream+pagemap@sigma-star.at \
    --cc=usama.anjum@collabora.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox