[PATCH RFC 07/29] mm/migrate: rename isolate_movable_page() to isolate_movable_ops_page()

[Alistair Popple]

On Mon, Jun 30, 2025 at 08:58:03AM +0800, Huang, Ying wrote:
> Alistair Popple <apopple at nvidia.com> writes:
> 
> > On Sun, Jun 29, 2025 at 07:28:50PM +0800, Huang, Ying wrote:
> >> David Hildenbrand <david at 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