linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Jann Horn <jannh@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/7] mm/mremap: introduce more mergeable mremap via MREMAP_RELOCATE_ANON
Date: Sun, 23 Mar 2025 13:49:07 +0100	[thread overview]
Message-ID: <335b3432-af06-420f-b575-7a1d92148f6b@redhat.com> (raw)
In-Reply-To: <2bdf7ac4-b359-420f-94fe-466ae98c4a49@lucifer.local>

>>
>> c)  In -next, there is now be the option to use folio lock +
>> folio_maybe_mapped_shared() == false. But it doesn't tell you into how many
>> VMAs a large folio is mapped into.
>>
>> In the following case:
>>
>> [       folio     ]
>> [ VMA#1 ] [ VMA#2 ]
>>
>> c) would not tell you if you are fine modifying the folio when moving VMA#2.
> 
> Right, I feel like prior checks made should assert this is not the case,
> however?  But mapcount check should be a last ditch assurance?

Something nice might be hiding in c) that might be able to handle a 
single folio being covered by multiple vmas.

I was thinking about the following:

[       folio0     ]
[       VMA#0      ]

Then we do a partial (old-school) mremap()

[ folio0 ]               [ folio0 ]
[ VMA#1  ]               [ VMA#2  ]

To then extend VMA#1 and fault in pages

[ folio0 ][ folio1 ]         [ folio0 ]
[      VMA#1       ]         [ VMA#2  ]

If that is possible (did not try!, maybe something prevents us from 
extending VMA#1) mremap(MREMAP_RELOCATE_ANON) of VMA#1  / VMA#2 cannot work.

We'd have to detect that scenario (partial mremap). You might be doing 
that with the anon-vma magic, something different might be: Assume we 
flag large folios if they were partially mremapped in any process.

Then (with folio lock only)

1) folio_maybe_mapped_shared() == false: mapped into single process
2) folio_maybe_partially_mremaped() == false: not scattered in virtual
    address space

It would be sufficient to check if the folio fully falls into the 
memap() range to decide if we can adjust the folio index etc.

We *might* be able to use that in the COW-reuse path for large folios to 
perform a folio_move_anon_rmap(), which we currently only perform for 
small folios / PMD-mapped folios (single mapping). Not sure yet if 
actually multiple VMAs are involved.



Just throwing it out there ...
> 
> (actually at least one of the 'prior checks' for large folios are added in a
> later commit but still :P)


Yeah, I'm looking at the bigger picture; small folios are easy :P


-- 
Cheers,

David / dhildenb



  reply	other threads:[~2025-03-23 12:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 21:54 [RFC PATCH 0/7] " Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 1/7] " Lorenzo Stoakes
2025-03-22  0:14   ` Jann Horn
2025-03-22  5:33     ` David Hildenbrand
2025-03-22  6:17       ` David Hildenbrand
2025-03-22  7:21         ` Lorenzo Stoakes
2025-03-23 12:53           ` David Hildenbrand
2025-03-31 14:19             ` Lorenzo Stoakes
2025-03-22  7:17       ` Lorenzo Stoakes
2025-03-23 12:49         ` David Hildenbrand [this message]
2025-03-31 14:50           ` Lorenzo Stoakes
2025-04-01 19:33             ` David Hildenbrand
2025-04-21 13:12             ` Lorenzo Stoakes
2025-03-22  7:07     ` Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 2/7] mm/mremap: add MREMAP_MUST_RELOCATE_ANON Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 3/7] mm/mremap: add MREMAP[_MUST]_RELOCATE_ANON support for THP folios Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 4/7] tools UAPI: Update copy of linux/mman.h from the kernel sources Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 5/7] tools/testing/selftests: add mremap() cases that merge normally Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 6/7] tools/testing/selftests: add MREMAP_RELOCATE_ANON merge test cases Lorenzo Stoakes
2025-03-21 21:54 ` [RFC PATCH 7/7] tools/testing/selftests: expand mremap() tests for MREMAP_RELOCATE_ANON 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=335b3432-af06-420f-b575-7a1d92148f6b@redhat.com \
    --to=david@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox