| Message ID | 20250306054532.221138-2-bharata@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Kernel daemon for detecting and promoting hot pages | expand |
On 06.03.25 06:45, Bharata B Rao wrote: > migrate_misplaced_folio_prepare() can be called from a > context where VMA isn't available. Allow the migration > to work from such contexts too. I was initially confused about "can be called", because it can't Consider phrasing it as "We want to make use of alloc_misplaced_dst_folio() in context where we don't have VMA information available. To prepare for that ..." > > Signed-off-by: Bharata B Rao <bharata@amd.com> > --- > mm/migrate.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/mm/migrate.c b/mm/migrate.c > index fb19a18892c8..5b21856a0dd0 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -2639,7 +2639,8 @@ static struct folio *alloc_misplaced_dst_folio(struct folio *src, > > /* > * Prepare for calling migrate_misplaced_folio() by isolating the folio if > - * permitted. Must be called with the PTL still held. > + * permitted. Must be called with the PTL still held if called with a non-NULL > + * vma. > */ > int migrate_misplaced_folio_prepare(struct folio *folio, > struct vm_area_struct *vma, int node) > @@ -2656,7 +2657,7 @@ int migrate_misplaced_folio_prepare(struct folio *folio, > * See folio_likely_mapped_shared() on possible imprecision > * when we cannot easily detect if a folio is shared. > */ > - if ((vma->vm_flags & VM_EXEC) && > + if (vma && (vma->vm_flags & VM_EXEC) && > folio_likely_mapped_shared(folio)) > return -EACCES; >
On Thu, Mar 06, 2025 at 11:15:29AM +0530, Bharata B Rao wrote: > migrate_misplaced_folio_prepare() can be called from a > context where VMA isn't available. Allow the migration > to work from such contexts too. > > Signed-off-by: Bharata B Rao <bharata@amd.com> I have a similar patch in the unmapped pagecache RFC we may also need this: https://lore.kernel.org/linux-mm/20250107000346.1338481-4-gourry@gourry.net/ May be worth just pulling these ahead to avoid conflict. ~Gregory
On Thu, Mar 06, 2025 at 12:24:16PM -0500, Gregory Price wrote: > On Thu, Mar 06, 2025 at 11:15:29AM +0530, Bharata B Rao wrote: > > migrate_misplaced_folio_prepare() can be called from a > > context where VMA isn't available. Allow the migration > > to work from such contexts too. > > > > Signed-off-by: Bharata B Rao <bharata@amd.com> > > I have a similar patch in the unmapped pagecache RFC > > we may also need this: > https://lore.kernel.org/linux-mm/20250107000346.1338481-4-gourry@gourry.net/ > > May be worth just pulling these ahead to avoid conflict. Or not putting them in at all because this whole thing is a magnificent waste of time?
On Thu, Mar 06, 2025 at 05:45:34PM +0000, Matthew Wilcox wrote: > On Thu, Mar 06, 2025 at 12:24:16PM -0500, Gregory Price wrote: > > we may also need this: > > https://lore.kernel.org/linux-mm/20250107000346.1338481-4-gourry@gourry.net/ > > > > May be worth just pulling these ahead to avoid conflict. > > Or not putting them in at all because this whole thing is a magnificent > waste of time? Divorced from the tiering mechanisms, is making misplaced migration able to migrate unmapped pages not generally useful? ~Gregory
On Thu, Mar 06, 2025 at 01:19:41PM -0500, Gregory Price wrote: > On Thu, Mar 06, 2025 at 05:45:34PM +0000, Matthew Wilcox wrote: > > On Thu, Mar 06, 2025 at 12:24:16PM -0500, Gregory Price wrote: > > > we may also need this: > > > https://lore.kernel.org/linux-mm/20250107000346.1338481-4-gourry@gourry.net/ > > > > > > May be worth just pulling these ahead to avoid conflict. > > > > Or not putting them in at all because this whole thing is a magnificent > > waste of time? > > Divorced from the tiering mechanisms, is making misplaced migration able > to migrate unmapped pages not generally useful? The only thing I can think of is if you have a process or set of processes on node A calling read() and the file is cached on node B. But in order to decide if the page is on the wrong node, you'd need to track a lot of information about which nodes the page is being accessed from. Which is probably why we've never bothered to do it. This is not a large patch for you to carry as part of your patchset. There's nothing intrinsically wrong with it; it just has no users in mainline and no real prospect of any being added soon.
On Thu, Mar 06, 2025 at 06:42:10PM +0000, Matthew Wilcox wrote: > On Thu, Mar 06, 2025 at 01:19:41PM -0500, Gregory Price wrote: > > Divorced from the tiering mechanisms, is making misplaced migration able > > to migrate unmapped pages not generally useful? > > The only thing I can think of is if you have a process or set of > processes on node A calling read() and the file is cached on node B. > But in order to decide if the page is on the wrong node, you'd need > to track a lot of information about which nodes the page is being > accessed from. Which is probably why we've never bothered to do it. > > This is not a large patch for you to carry as part of your patchset. > There's nothing intrinsically wrong with it; it just has no users in > mainline and no real prospect of any being added soon. That's fair, I'm just tracking 3-4 different RFCs that are going to butt up against this, so wanted to assess whether getting the patches out ahead would save some strife. ~Gregory
On 06-Mar-25 5:43 PM, David Hildenbrand wrote: > On 06.03.25 06:45, Bharata B Rao wrote: >> migrate_misplaced_folio_prepare() can be called from a >> context where VMA isn't available. Allow the migration >> to work from such contexts too. > > I was initially confused about "can be called", because it can't > > Consider phrasing it as "We want to make use of > alloc_misplaced_dst_folio() in context where we don't have VMA > information available. To prepare for that ..." Yes, that would be the right wording. Thanks, Bharata.
diff --git a/mm/migrate.c b/mm/migrate.c index fb19a18892c8..5b21856a0dd0 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2639,7 +2639,8 @@ static struct folio *alloc_misplaced_dst_folio(struct folio *src, /* * Prepare for calling migrate_misplaced_folio() by isolating the folio if - * permitted. Must be called with the PTL still held. + * permitted. Must be called with the PTL still held if called with a non-NULL + * vma. */ int migrate_misplaced_folio_prepare(struct folio *folio, struct vm_area_struct *vma, int node) @@ -2656,7 +2657,7 @@ int migrate_misplaced_folio_prepare(struct folio *folio, * See folio_likely_mapped_shared() on possible imprecision * when we cannot easily detect if a folio is shared. */ - if ((vma->vm_flags & VM_EXEC) && + if (vma && (vma->vm_flags & VM_EXEC) && folio_likely_mapped_shared(folio)) return -EACCES;
migrate_misplaced_folio_prepare() can be called from a context where VMA isn't available. Allow the migration to work from such contexts too. Signed-off-by: Bharata B Rao <bharata@amd.com> --- mm/migrate.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)