... and start moving back to per-page things that will absolutely not be
folio things in the future. Add documentation and a comment that the
remaining folio stuff (lock, refcount) will have to be reworked as well.
While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle
it gracefully (relevant with further changes), and convert a
WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE().
Signed-off-by: David Hildenbrand <david@redhat.com>
---
include/linux/migrate.h | 4 ++--
mm/compaction.c | 2 +-
mm/migrate.c | 39 +++++++++++++++++++++++++++++----------
3 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index aaa2114498d6d..c0ec7422837bd 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -69,7 +69,7 @@ int migrate_pages(struct list_head *l, new_folio_t new, free_folio_t free,
unsigned long private, enum migrate_mode mode, int reason,
unsigned int *ret_succeeded);
struct folio *alloc_migration_target(struct folio *src, unsigned long private);
-bool isolate_movable_page(struct page *page, isolate_mode_t mode);
+bool isolate_movable_ops_page(struct page *page, isolate_mode_t mode);
bool isolate_folio_to_list(struct folio *folio, struct list_head *list);
int migrate_huge_page_move_mapping(struct address_space *mapping,
@@ -90,7 +90,7 @@ static inline int migrate_pages(struct list_head *l, new_folio_t new,
static inline struct folio *alloc_migration_target(struct folio *src,
unsigned long private)
{ return NULL; }
-static inline bool isolate_movable_page(struct page *page, isolate_mode_t mode)
+static inline bool isolate_movable_ops_page(struct page *page, isolate_mode_t mode)
{ return false; }
static inline bool isolate_folio_to_list(struct folio *folio, struct list_head *list)
{ return false; }
diff --git a/mm/compaction.c b/mm/compaction.c
index 3925cb61dbb8f..17455c5a4be05 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1093,7 +1093,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
locked = NULL;
}
- if (isolate_movable_page(page, mode)) {
+ if (isolate_movable_ops_page(page, mode)) {
folio = page_folio(page);
goto isolate_success;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index ea8c74d996592..6bbb455f8b593 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -51,8 +51,26 @@
#include "internal.h"
#include "swap.h"
-bool isolate_movable_page(struct page *page, isolate_mode_t mode)
+/**
+ * isolate_movable_ops_page - isolate a movable_ops page for migration
+ * @page: The page.
+ * @mode: The isolation mode.
+ *
+ * Try to isolate a movable_ops page for migration. Will fail if the page is
+ * not a movable_ops page, if the page is already isolated for migration
+ * or if the page was just was released by its owner.
+ *
+ * Once isolated, the page cannot get freed until it is either putback
+ * or migrated.
+ *
+ * Returns true if isolation succeeded, otherwise false.
+ */
+bool isolate_movable_ops_page(struct page *page, isolate_mode_t mode)
{
+ /*
+ * TODO: these pages will not be folios in the future. All
+ * folio dependencies will have to be removed.
+ */
struct folio *folio = folio_get_nontail_page(page);
const struct movable_operations *mops;
@@ -73,7 +91,7 @@ bool isolate_movable_page(struct page *page, isolate_mode_t mode)
* we use non-atomic bitops on newly allocated page flags so
* unconditionally grabbing the lock ruins page's owner side.
*/
- if (unlikely(!__folio_test_movable(folio)))
+ if (unlikely(!__PageMovable(page)))
goto out_putfolio;
/*
@@ -90,18 +108,19 @@ bool isolate_movable_page(struct page *page, isolate_mode_t mode)
if (unlikely(!folio_trylock(folio)))
goto out_putfolio;
- if (!folio_test_movable(folio) || folio_test_isolated(folio))
+ if (!PageMovable(page) || PageIsolated(page))
goto out_no_isolated;
- mops = folio_movable_ops(folio);
- VM_BUG_ON_FOLIO(!mops, folio);
+ mops = page_movable_ops(page);
+ if (WARN_ON_ONCE(!mops))
+ goto out_no_isolated;
- if (!mops->isolate_page(&folio->page, mode))
+ if (!mops->isolate_page(page, mode))
goto out_no_isolated;
/* Driver shouldn't use the isolated flag */
- WARN_ON_ONCE(folio_test_isolated(folio));
- folio_set_isolated(folio);
+ VM_WARN_ON_ONCE_PAGE(PageIsolated(page), page);
+ SetPageIsolated(page);
folio_unlock(folio);
return true;
@@ -175,8 +194,8 @@ bool isolate_folio_to_list(struct folio *folio, struct list_head *list)
if (lru)
isolated = folio_isolate_lru(folio);
else
- isolated = isolate_movable_page(&folio->page,
- ISOLATE_UNEVICTABLE);
+ isolated = isolate_movable_ops_page(&folio->page,
+ ISOLATE_UNEVICTABLE);
if (!isolated)
return false;
--
2.49.0On Wed, Jun 18, 2025 at 07:39:50PM +0200, David Hildenbrand wrote: > ... and start moving back to per-page things that will absolutely not be > folio things in the future. Add documentation and a comment that the > remaining folio stuff (lock, refcount) will have to be reworked as well. > > While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle > it gracefully (relevant with further changes), and convert a > WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). > > Signed-off-by: David Hildenbrand <david@redhat.com> > --- Haha yeah, back to pages after folio conversion :P But makes sense. Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Side question: In the future, maybe we will be unable to tell whether a page is compound or not, without first inspecting page->memdesc? (e.g., struct slab could have an order and a pointer to the head page... just imagining). -- Cheers, Harry / Hyeonggon
On 30.06.25 10:04, Harry Yoo wrote: > On Wed, Jun 18, 2025 at 07:39:50PM +0200, David Hildenbrand wrote: >> ... and start moving back to per-page things that will absolutely not be >> folio things in the future. Add documentation and a comment that the >> remaining folio stuff (lock, refcount) will have to be reworked as well. >> >> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >> it gracefully (relevant with further changes), and convert a >> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >> >> Signed-off-by: David Hildenbrand <david@redhat.com> >> --- > > Haha yeah, back to pages after folio conversion :P > But makes sense. > > Reviewed-by: Harry Yoo <harry.yoo@oracle.com> > > Side question: In the future, maybe we will be unable to tell whether > a page is compound or not, without first inspecting page->memdesc? > (e.g., struct slab could have an order and a pointer to the head page... > just imagining). Right, it's not really clear what we would do in the future, but for anything that allocates a memdesc, that is possible. We wouldn't even need the "head" + "tail" bit indication. For things without an allocated memdesc (e.g., PageOffline), maybe compound pages will simply not apply. Likely, the concept of compound pages as we knew it will go away. -- Cheers, David / dhildenb
On 18 Jun 2025, at 13:39, David Hildenbrand wrote: > ... and start moving back to per-page things that will absolutely not be > folio things in the future. Add documentation and a comment that the > remaining folio stuff (lock, refcount) will have to be reworked as well. > > While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle > it gracefully (relevant with further changes), and convert a > WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). The reason is that there is no upstream code, which use movable_ops for folios? Is there any fundamental reason preventing movable_ops from being used on folios? Best Regards, Yan, Zi
On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: > On 18 Jun 2025, at 13:39, David Hildenbrand wrote: > > > ... and start moving back to per-page things that will absolutely not be > > folio things in the future. Add documentation and a comment that the > > remaining folio stuff (lock, refcount) will have to be reworked as well. > > > > While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle > > it gracefully (relevant with further changes), and convert a > > WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). > > The reason is that there is no upstream code, which use movable_ops for > folios? Is there any fundamental reason preventing movable_ops from > being used on folios? folios either belong to a filesystem or they are anonymous memory, and so either the filesystem knows how to migrate them (through its a_ops) or the migration code knows how to handle anon folios directly.
On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: > On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >> >>> ... and start moving back to per-page things that will absolutely not be >>> folio things in the future. Add documentation and a comment that the >>> remaining folio stuff (lock, refcount) will have to be reworked as well. >>> >>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >>> it gracefully (relevant with further changes), and convert a >>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >> >> The reason is that there is no upstream code, which use movable_ops for >> folios? Is there any fundamental reason preventing movable_ops from >> being used on folios? > > folios either belong to a filesystem or they are anonymous memory, and > so either the filesystem knows how to migrate them (through its a_ops) > or the migration code knows how to handle anon folios directly. for device private pages, to support migrating >0 order anon or fs folios to device, how should we represent them for devices? if you think folio is only for anon and fs. Best Regards, Yan, Zi
On 18.06.25 20:48, Zi Yan wrote: > On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: > >> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >>> >>>> ... and start moving back to per-page things that will absolutely not be >>>> folio things in the future. Add documentation and a comment that the >>>> remaining folio stuff (lock, refcount) will have to be reworked as well. >>>> >>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >>>> it gracefully (relevant with further changes), and convert a >>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >>> >>> The reason is that there is no upstream code, which use movable_ops for >>> folios? Is there any fundamental reason preventing movable_ops from >>> being used on folios? >> >> folios either belong to a filesystem or they are anonymous memory, and >> so either the filesystem knows how to migrate them (through its a_ops) >> or the migration code knows how to handle anon folios directly. Right, migration of folios will be handled by migration core. > > for device private pages, to support migrating >0 order anon or fs folios > to device, how should we represent them for devices? if you think folio is > only for anon and fs. I assume they are proper folios, so yes. Just like they are handled today (-> folios) I was asking a related question at LSF/MM in Alistair's session: are we sure these things will be folios even before they are assigned to a filesystem? I recall the answer was "yes". So we don't (and will not) support movable_ops for folios. -- Cheers, David / dhildenb
David Hildenbrand <david@redhat.com> writes: > On 18.06.25 20:48, Zi Yan wrote: >> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: >> >>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >>>> >>>>> ... and start moving back to per-page things that will absolutely not be >>>>> folio things in the future. Add documentation and a comment that the >>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. >>>>> >>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >>>>> it gracefully (relevant with further changes), and convert a >>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >>>> >>>> The reason is that there is no upstream code, which use movable_ops for >>>> folios? Is there any fundamental reason preventing movable_ops from >>>> being used on folios? >>> >>> folios either belong to a filesystem or they are anonymous memory, and >>> so either the filesystem knows how to migrate them (through its a_ops) >>> or the migration code knows how to handle anon folios directly. > > Right, migration of folios will be handled by migration core. > >> for device private pages, to support migrating >0 order anon or fs >> folios >> to device, how should we represent them for devices? if you think folio is >> only for anon and fs. > > I assume they are proper folios, so yes. Just like they are handled > today (-> folios) > > I was asking a related question at LSF/MM in Alistair's session: are > we sure these things will be folios even before they are assigned to a > filesystem? I recall the answer was "yes". > > So we don't (and will not) support movable_ops for folios. Is it possible to use some device specific callbacks (DMA?) to copy from/to the device private folios (or pages) to/from the normal file/anon folios in the future? --- Best Regards, Huang, Ying
On Sun, Jun 29, 2025 at 07:28:50PM +0800, Huang, Ying wrote: > David Hildenbrand <david@redhat.com> writes: > > > On 18.06.25 20:48, Zi Yan wrote: > >> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: > >> > >>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: > >>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: > >>>> > >>>>> ... and start moving back to per-page things that will absolutely not be > >>>>> folio things in the future. Add documentation and a comment that the > >>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. > >>>>> > >>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle > >>>>> it gracefully (relevant with further changes), and convert a > >>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). > >>>> > >>>> The reason is that there is no upstream code, which use movable_ops for > >>>> folios? Is there any fundamental reason preventing movable_ops from > >>>> being used on folios? > >>> > >>> folios either belong to a filesystem or they are anonymous memory, and > >>> so either the filesystem knows how to migrate them (through its a_ops) > >>> or the migration code knows how to handle anon folios directly. > > > > Right, migration of folios will be handled by migration core. > > > >> for device private pages, to support migrating >0 order anon or fs > >> folios > >> to device, how should we represent them for devices? if you think folio is > >> only for anon and fs. > > > > I assume they are proper folios, so yes. Just like they are handled > > today (-> folios) Yes, they should be proper folios. > > I was asking a related question at LSF/MM in Alistair's session: are > > we sure these things will be folios even before they are assigned to a > > filesystem? I recall the answer was "yes". > > > > So we don't (and will not) support movable_ops for folios. > > Is it possible to use some device specific callbacks (DMA?) to copy > from/to the device private folios (or pages) to/from the normal > file/anon folios in the future? I guess we could put such callbacks on the folio->pgmap, but I'm not sure why we would want to. Currently all migration to/from device private (or coherent) folios is managed by the device, which is one of the features of ZONE_DEVICE. Did you have some particular reason/idea for why we might want to do this? > --- > Best Regards, > Huang, Ying
Alistair Popple <apopple@nvidia.com> writes: > On Sun, Jun 29, 2025 at 07:28:50PM +0800, Huang, Ying wrote: >> David Hildenbrand <david@redhat.com> writes: >> >> > On 18.06.25 20:48, Zi Yan wrote: >> >> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: >> >> >> >>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >> >>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >> >>>> >> >>>>> ... and start moving back to per-page things that will absolutely not be >> >>>>> folio things in the future. Add documentation and a comment that the >> >>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. >> >>>>> >> >>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >> >>>>> it gracefully (relevant with further changes), and convert a >> >>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >> >>>> >> >>>> The reason is that there is no upstream code, which use movable_ops for >> >>>> folios? Is there any fundamental reason preventing movable_ops from >> >>>> being used on folios? >> >>> >> >>> folios either belong to a filesystem or they are anonymous memory, and >> >>> so either the filesystem knows how to migrate them (through its a_ops) >> >>> or the migration code knows how to handle anon folios directly. >> > >> > Right, migration of folios will be handled by migration core. >> > >> >> for device private pages, to support migrating >0 order anon or fs >> >> folios >> >> to device, how should we represent them for devices? if you think folio is >> >> only for anon and fs. >> > >> > I assume they are proper folios, so yes. Just like they are handled >> > today (-> folios) > > Yes, they should be proper folios. So, folios include file cache, anonymous, and some device private. >> > I was asking a related question at LSF/MM in Alistair's session: are >> > we sure these things will be folios even before they are assigned to a >> > filesystem? I recall the answer was "yes". >> > >> > So we don't (and will not) support movable_ops for folios. >> >> Is it possible to use some device specific callbacks (DMA?) to copy >> from/to the device private folios (or pages) to/from the normal >> file/anon folios in the future? > > I guess we could put such callbacks on the folio->pgmap, but I'm not sure why > we would want to. Currently all migration to/from device private (or coherent) > folios is managed by the device, which is one of the features of ZONE_DEVICE. Yes. The is the current behavior per my understanding too. > Did you have some particular reason/idea for why we might want to do this? No. Just want to check whether there are some requirements for that. I think that it's just another way to organize code. --- Best Regards, Huang, Ying
On Mon, Jun 30, 2025 at 08:58:03AM +0800, Huang, Ying wrote: > Alistair Popple <apopple@nvidia.com> writes: > > > On Sun, Jun 29, 2025 at 07:28:50PM +0800, Huang, Ying wrote: > >> David Hildenbrand <david@redhat.com> writes: > >> > >> > On 18.06.25 20:48, Zi Yan wrote: > >> >> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: > >> >> > >> >>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: > >> >>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: > >> >>>> > >> >>>>> ... and start moving back to per-page things that will absolutely not be > >> >>>>> folio things in the future. Add documentation and a comment that the > >> >>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. > >> >>>>> > >> >>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle > >> >>>>> it gracefully (relevant with further changes), and convert a > >> >>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). > >> >>>> > >> >>>> The reason is that there is no upstream code, which use movable_ops for > >> >>>> folios? Is there any fundamental reason preventing movable_ops from > >> >>>> being used on folios? > >> >>> > >> >>> folios either belong to a filesystem or they are anonymous memory, and > >> >>> so either the filesystem knows how to migrate them (through its a_ops) > >> >>> or the migration code knows how to handle anon folios directly. > >> > > >> > Right, migration of folios will be handled by migration core. > >> > > >> >> for device private pages, to support migrating >0 order anon or fs > >> >> folios > >> >> to device, how should we represent them for devices? if you think folio is > >> >> only for anon and fs. > >> > > >> > I assume they are proper folios, so yes. Just like they are handled > >> > today (-> folios) > > > > Yes, they should be proper folios. > > So, folios include file cache, anonymous, and some device private. Oh maybe I misunderstood what you were asking. We have anon and fs folios, and we currently have device private versions of the former. However ideally I think in a memdesc world we would have anon/fs folios, and the device private bit would be in the memdesc or some such and so at the level of a folio we'd only be dealing with "proper" anon or fs folios (of course in practice we may never permit device private versions of the latter). In my earlier answer I just wanted to highlight the fact that order >0 device folios now look the same as normal higher order anon or fs folios. Ie. we don't do any of the special pgmap refcounting, etc. that we used to do for higher order device folios. > >> > I was asking a related question at LSF/MM in Alistair's session: are > >> > we sure these things will be folios even before they are assigned to a > >> > filesystem? I recall the answer was "yes". > >> > > >> > So we don't (and will not) support movable_ops for folios. > >> > >> Is it possible to use some device specific callbacks (DMA?) to copy > >> from/to the device private folios (or pages) to/from the normal > >> file/anon folios in the future? > > > > I guess we could put such callbacks on the folio->pgmap, but I'm not sure why > > we would want to. Currently all migration to/from device private (or coherent) > > folios is managed by the device, which is one of the features of ZONE_DEVICE. > > Yes. The is the current behavior per my understanding too. > > > Did you have some particular reason/idea for why we might want to do this? > > No. Just want to check whether there are some requirements for that. I > think that it's just another way to organize code. > > --- > Best Regards, > Huang, Ying
On 23 Jun 2025, at 11:33, David Hildenbrand wrote: > On 18.06.25 20:48, Zi Yan wrote: >> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: >> >>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >>>> >>>>> ... and start moving back to per-page things that will absolutely not be >>>>> folio things in the future. Add documentation and a comment that the >>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. >>>>> >>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >>>>> it gracefully (relevant with further changes), and convert a >>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >>>> >>>> The reason is that there is no upstream code, which use movable_ops for >>>> folios? Is there any fundamental reason preventing movable_ops from >>>> being used on folios? >>> >>> folios either belong to a filesystem or they are anonymous memory, and >>> so either the filesystem knows how to migrate them (through its a_ops) >>> or the migration code knows how to handle anon folios directly. > > Right, migration of folios will be handled by migration core. > >> >> for device private pages, to support migrating >0 order anon or fs folios >> to device, how should we represent them for devices? if you think folio is >> only for anon and fs. > > I assume they are proper folios, so yes. Just like they are handled today (-> folios) > > I was asking a related question at LSF/MM in Alistair's session: are we sure these things will be folios even before they are assigned to a filesystem? I recall the answer was "yes". > > So we don't (and will not) support movable_ops for folios. Got it. (I was abusing it to help develop alloc_contig_range() at pageblock granularity, since it was easy to write a driver to allocate a compound page at a specific PFN and claim the page is movable, then do page online/offline the range containing the PFNs. :) ) For the patch, Reviewed-by: Zi Yan <ziy@nvidia.com> -- Best Regards, Yan, Zi
On 23.06.25 17:42, Zi Yan wrote: > On 23 Jun 2025, at 11:33, David Hildenbrand wrote: > >> On 18.06.25 20:48, Zi Yan wrote: >>> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: >>> >>>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >>>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >>>>> >>>>>> ... and start moving back to per-page things that will absolutely not be >>>>>> folio things in the future. Add documentation and a comment that the >>>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. >>>>>> >>>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >>>>>> it gracefully (relevant with further changes), and convert a >>>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >>>>> >>>>> The reason is that there is no upstream code, which use movable_ops for >>>>> folios? Is there any fundamental reason preventing movable_ops from >>>>> being used on folios? >>>> >>>> folios either belong to a filesystem or they are anonymous memory, and >>>> so either the filesystem knows how to migrate them (through its a_ops) >>>> or the migration code knows how to handle anon folios directly. >> >> Right, migration of folios will be handled by migration core. >> >>> >>> for device private pages, to support migrating >0 order anon or fs folios >>> to device, how should we represent them for devices? if you think folio is >>> only for anon and fs. >> >> I assume they are proper folios, so yes. Just like they are handled today (-> folios) >> >> I was asking a related question at LSF/MM in Alistair's session: are we sure these things will be folios even before they are assigned to a filesystem? I recall the answer was "yes". >> >> So we don't (and will not) support movable_ops for folios. > > Got it. (I was abusing it to help develop alloc_contig_range() at pageblock > granularity, since it was easy to write a driver to allocate a compound page > at a specific PFN and claim the page is movable, then do page online/offline > the range containing the PFNs. :) ) > > For the patch, Reviewed-by: Zi Yan <ziy@nvidia.com> BTW, thinking about it, I think we could handle compound pages quite easily, we'd just have to lookup the head at some point -- but we wouldn't be using folios for that. BUT, I am note sure how compound pages without a memdesc would look like in a memdesc world, and if it would actually be "compound pages" in the traditional sense. So, I think there would be ways to handle that, once we get to it. -- Cheers, David / dhildenb
On 23.06.25 17:42, Zi Yan wrote: > On 23 Jun 2025, at 11:33, David Hildenbrand wrote: > >> On 18.06.25 20:48, Zi Yan wrote: >>> On 18 Jun 2025, at 14:39, Matthew Wilcox wrote: >>> >>>> On Wed, Jun 18, 2025 at 02:14:15PM -0400, Zi Yan wrote: >>>>> On 18 Jun 2025, at 13:39, David Hildenbrand wrote: >>>>> >>>>>> ... and start moving back to per-page things that will absolutely not be >>>>>> folio things in the future. Add documentation and a comment that the >>>>>> remaining folio stuff (lock, refcount) will have to be reworked as well. >>>>>> >>>>>> While at it, convert the VM_BUG_ON() into a WARN_ON_ONCE() and handle >>>>>> it gracefully (relevant with further changes), and convert a >>>>>> WARN_ON_ONCE() into a VM_WARN_ON_ONCE_PAGE(). >>>>> >>>>> The reason is that there is no upstream code, which use movable_ops for >>>>> folios? Is there any fundamental reason preventing movable_ops from >>>>> being used on folios? >>>> >>>> folios either belong to a filesystem or they are anonymous memory, and >>>> so either the filesystem knows how to migrate them (through its a_ops) >>>> or the migration code knows how to handle anon folios directly. >> >> Right, migration of folios will be handled by migration core. >> >>> >>> for device private pages, to support migrating >0 order anon or fs folios >>> to device, how should we represent them for devices? if you think folio is >>> only for anon and fs. >> >> I assume they are proper folios, so yes. Just like they are handled today (-> folios) >> >> I was asking a related question at LSF/MM in Alistair's session: are we sure these things will be folios even before they are assigned to a filesystem? I recall the answer was "yes". >> >> So we don't (and will not) support movable_ops for folios. > > Got it. (I was abusing it to help develop alloc_contig_range() at pageblock > granularity, since it was easy to write a driver to allocate a compound page > at a specific PFN and claim the page is movable, then do page online/offline > the range containing the PFNs. :) ) Oh, interesting :) Yeah, with a folio that will be a bit harder ... > > For the patch, Reviewed-by: Zi Yan <ziy@nvidia.com> Thanks! -- Cheers, David / dhildenb
© 2016 - 2025 Red Hat, Inc.