From: Matthew Wilcox <willy@infradead.org>
To: David Hildenbrand <david@redhat.com>
Cc: lsf-pc@lists.linux-foundation.org,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [LSF/MM/BPF TOPIC] page table reclaim
Date: Thu, 24 Feb 2022 20:09:19 +0000 [thread overview]
Message-ID: <Yhfl75OlDZnVIW2e@casper.infradead.org> (raw)
In-Reply-To: <7b908208-02f8-6fde-4dfc-13d5e00310a6@redhat.com>
On Tue, Feb 22, 2022 at 09:56:20AM +0100, David Hildenbrand wrote:
> 2. Who triggers reclaim and when?
>
> Letting an application trigger reclaim of page tables is the "easiest
> solution": let's imagine madvise(MADV_RECLAIM_PGTABLES). However, this
> doesn't take care of malicious workloads and is more problematic when
> having sparse files mapped into multiple processes. Further, there is no
> need to reclaim if we're not under memory pressure.
>
> Letting the system do this automatically looks "cleaner". But, when to
> start reclaiming? How to detect and handle malicious processes (do we
> care?)? How to set an adequate soft/hard limit?
I don't think we care about the difference between users that are
performing useful work with an inefficient page table strategy and users
that are trying to break the page table usage scheme. We have to account
the page tables to each process (which we already do), and a process which
is, say, trying to allocate memory might be shunted off to a path where
it tries to reclaim its own page tables if it has a lot on the books.
Particularly if it's trying to allocate memory for more page tables ;-)
> While I do have answers to some of the questions and various ideas, it's
> certainly an interesting topic to discuss and brainstorm.
Indeed; it interests me too.
prev parent reply other threads:[~2022-02-24 20:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 8:56 David Hildenbrand
2022-02-24 20:09 ` Matthew Wilcox [this message]
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=Yhfl75OlDZnVIW2e@casper.infradead.org \
--to=willy@infradead.org \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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