From: David Hildenbrand <david@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: The future of PageAnonExclusive
Date: Wed, 11 Dec 2024 16:50:12 +0100 [thread overview]
Message-ID: <42869071-64a9-47d1-867d-9ddede6bf430@redhat.com> (raw)
In-Reply-To: <Z1mzn0SCOigQkFvP@casper.infradead.org>
On 11.12.24 16:45, Matthew Wilcox wrote:
> On Wed, Dec 11, 2024 at 03:49:12PM +0100, David Hildenbrand wrote:
>> On 11.12.24 15:25, Ryan Roberts wrote:
>>> On 11/12/2024 11:56, David Hildenbrand wrote:
>>>> Now CCing the correct Willy :)
>>>>
>>>> On 11.12.24 12:55, David Hildenbrand wrote:
>>>>> Hi,
>>>>>
>>>>> PageAnonExclusive (PAE) is working very reliable at this point. But
>>>>> especially in the context of THPs (large folios) we'd like to do better:
>>>>>
>>>>> (1) For PTE-mapped THP, we have to maintain it per page. We'd like to
>>>>> avoid per-page flags as good as possible (e.g., waste in "struct
>>>>> page", touching many cachelines).
>>>
>>> Presumably also important for the Glorious Future where struct page is just a
>>> pointer and struct folio (et al) is allocated dynamically?
>>
>> I think Willy mentioned that there might be ways to encode it in the 8-byte
>> for the "tail" pages.
>
> Yes. For anon memory, the page->memdesc has a 4-bit 'type' and the
> remaining 60 bits is a pointer to a struct folio (allocated from a slab
> with 16 byte alignment). The current list of types [1] has file folios
> as type 2 and anon folios as type 3. We could allocate a type to be
> 'anon exclusive', thus essentially giving us an anon-exclusive bit.
Right.
>
> [1] https://kernelnewbies.org/MatthewWilcox/Memdescs
>
> Don't get too excited about "we're almost out of types". The "managed"
> type has subtypes. We could also collapse "file" and "anon" into a
> single type and distinguish between them with a bit in the folio.
>
> Anyway, yes, we can do one per-page flag. Two per-page flags starts to
> get dicey.
hwpoison? :/
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-12-11 15:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 11:55 The future of PageAnonExclusive David Hildenbrand
2024-12-11 11:56 ` David Hildenbrand
2024-12-11 13:42 ` Kirill A. Shutemov
2024-12-11 13:48 ` David Hildenbrand
2024-12-11 14:25 ` Ryan Roberts
2024-12-11 14:49 ` David Hildenbrand
2024-12-11 15:45 ` Matthew Wilcox
2024-12-11 15:50 ` David Hildenbrand [this message]
2024-12-11 16:11 ` Matthew Wilcox
2024-12-11 16:15 ` David Hildenbrand
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=42869071-64a9-47d1-867d-9ddede6bf430@redhat.com \
--to=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.