On 07.06.22 21:21, Matthew Wilcox wrote:
> On Tue, Jun 07, 2022 at 03:24:15PM +0100, Matthew Wilcox wrote:
>> On Tue, Jun 07, 2022 at 09:36:21AM +0200, David Hildenbrand wrote:
>>> On 06.06.22 22:40, Matthew Wilcox (Oracle) wrote:
>>>> const struct address_space_operations balloon_aops = {
>>>> - .migratepage = balloon_page_migrate,
>>>> + .migrate_folio = balloon_migrate_folio,
>>>> .isolate_page = balloon_page_isolate,
>>>> .putback_page = balloon_page_putback,
>>>> };
>>>
>>> I assume you're working on conversion of the other callbacks as well,
>>> because otherwise, this ends up looking a bit inconsistent and confusing :)
>>
>> My intention was to finish converting aops for the next merge window.
>>
>> However, it seems to me that we goofed back in 2016 by merging
>> commit bda807d44454. isolate_page() and putback_page() should
>> never have been part of address_space_operations.
>>
>> I'm about to embark on creating a new migrate_operations struct
>> for drivers to use that contains only isolate/putback/migrate.
>> No filesystem uses isolate/putback, so those can just be deleted.
>> Both migrate_operations & address_space_operations will contain a
>> migrate callback.
That makes sense to me. I wonder if there was a design
decision/discussion behind that. CCing Rafael.
@Rafael, full mail at
https://lkml.kernel.org/r/Yp+lU55H4igaV3pB@xxxxxxxxxxxxxxxxxxxx
>
> Well, that went more smoothly than I thought it would.
>
> I can't see a nice way to split this patch up (other than making secretmem
> its own patch). We just don't have enough bits in struct page to support
> both ways of handling PageMovable at the same time, so we can't convert
> one driver at a time. The diffstat is pretty compelling.
Yes, splitting rather overcomplicates stuff.
>
> The patch is on top of this patch series; I think it probably makes
> sense to shuffle it to be first, to avoid changing these drivers to
> folios, then changing them back.
Absolutely.
>
> Questions:
>
> Is what I've done with zsmalloc acceptable? The locking in that
> file is rather complex.
>
> Can we now eliminate balloon_mnt / balloon_fs from cmm.c? I haven't even
> compiled thatfile , but it seems like the filesystem serves no use now.
>
> Similar question for vmw_balloon.c, although I have compiled that.
IIRC, virtio-balloon, cmm and vmw_balloon all have the mnt/fs just for
page migration purposes. So if one can get rid of them, all should be
able to get rid of them. Essentially everything that uses the balloon
compaction framework.
That should go into separate patches then.
>
> ---
>
> I just spotted a bug with zs_unregister_migration(); it won't compile
> without CONFIG_MIGRATION. I'll fix that up if the general approach is
> acceptable.
>
> arch/powerpc/platforms/pseries/cmm.c | 13 --------
> drivers/misc/vmw_balloon.c | 10 ------
> include/linux/balloon_compaction.h | 6 +---
> include/linux/fs.h | 2 -
> include/linux/migrate.h | 27 ++++++++++++++----
> include/linux/page-flags.h | 2 -
> mm/balloon_compaction.c | 18 ++++++------
> mm/compaction.c | 29 ++++++++-----------
> mm/migrate.c | 23 ++++++++-------
> mm/secretmem.c | 6 ----
> mm/util.c | 4 +-
> mm/z3fold.c | 45 ++++++------------------------
> mm/zsmalloc.c | 52 +++++++++--------------------------
> 13 files changed, 83 insertions(+), 154 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/cmm.c b/arch/powerpc/platforms/pseries/cmm.c
> index 15ed8206c463..2ecbab3db723 100644
> --- a/arch/powerpc/platforms/pseries/cmm.c
> +++ b/arch/powerpc/platforms/pseries/cmm.c
> @@ -578,23 +578,10 @@ static int cmm_balloon_compaction_init(void)
> return rc;
> }
>
> - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> - if (IS_ERR(b_dev_info.inode)) {
> - rc = PTR_ERR(b_dev_info.inode);
> - b_dev_info.inode = NULL;
> - kern_unmount(balloon_mnt);
> - balloon_mnt = NULL;
> - return rc;
> - }
> -
> - b_dev_info.inode->i_mapping->a_ops = &balloon_aops;
Are you missing similar updates to drivers/virtio/virtio_balloon.c ?
At least, there we're also using balloon_aops, so this patch shouldn't
compile.
Skimming over it, nothing else jumped at me.
--
Thanks,
David / dhildenb
