From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2A3DC433EF for ; Wed, 8 Jun 2022 09:59:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32B538D001E; Wed, 8 Jun 2022 05:59:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B4C46B00B4; Wed, 8 Jun 2022 05:59:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12DD88D001E; Wed, 8 Jun 2022 05:59:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F16C76B00B3 for ; Wed, 8 Jun 2022 05:59:37 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C8D81206BB for ; Wed, 8 Jun 2022 09:59:37 +0000 (UTC) X-FDA: 79554621594.03.E8B715B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id D49AD120049 for ; Wed, 8 Jun 2022 09:59:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654682376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=HTgr1iTc2yNBJ1TMG1abAXJSSpfxGYB6q8DDg6rnb5L77rqSUjLmyMcw5MKS9W8Bqf+0lQ ibC36RSLfFLbCsI4FDLUl0aYLyQa6T26wEi9aO21DVIT3Gz7UrtMwowP+cKEuztqrX1UQe 1eaWq5xsDk+ZtqJ0xrl8XsuNvnaiHOY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-618-Cqm9x1UAMmWha9qag78NmA-1; Wed, 08 Jun 2022 05:59:35 -0400 X-MC-Unique: Cqm9x1UAMmWha9qag78NmA-1 Received: by mail-wm1-f72.google.com with SMTP id c187-20020a1c35c4000000b003970013833aso6813423wma.1 for ; Wed, 08 Jun 2022 02:59:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=X7ko0a61KQIEYlZE2OolrSj5KPboqylHtHlNY2Rk0xk=; b=flp8U4mTZmXbsXUFLZ8DBeR/V5zVmpWZHQ9r1H8eLW27Nfy83wDB22URBHf7mAKbEP X2Drv07VzGmT0khGh0jfe9gWhCATLFA1PsXOHcsMUNro0LJMo9CPlm3Ws51Wn5PerkWU mdccrnDTzG0dfFo3vAqnHvBsHXgVjYjMYdL7ULhIcQQLGZFr461d64bKEi6fK3O8f0gr 1LiTbkdIhmDcMdpcWJYHTfxEzgOohI3X/hQuXvNTOcX0yJL4i9pSZ3QcDmoJfPDX32da R42q8tF5s5vAJWHxpsOL5marKHlquFq9plqRnvNCxfNA+9pnT6q6+DE6SrcuiWrR5Rqn 25Zw== X-Gm-Message-State: AOAM530bwsAVlO3+f1BFJXF4HO/3V0kApOaweBXIXokevCSiI0xRBkpr EDhdjMjnkijpfMho6VD60Lx19NWmeCCyVFV3nOND9JiFB3rTTVEvdAcTuSs+uRUhEnuu/gmEbVj GU6N+qvePya4= X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665184wmg.102.1654682374064; Wed, 08 Jun 2022 02:59:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw4BCTXIM51kCwL6Z6H/hpvqsMvzu1fv9X/GhiUOzp5r00CIAo0BKvmPAyhZ/PubqP5kGP1SQ== X-Received: by 2002:a05:600c:154d:b0:394:8d64:9166 with SMTP id f13-20020a05600c154d00b003948d649166mr33665171wmg.102.1654682373804; Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:ad00:db2:4c6:8f3a:2ec4? (p200300cbc705ad000db204c68f3a2ec4.dip0.t-ipconnect.de. [2003:cb:c705:ad00:db2:4c6:8f3a:2ec4]) by smtp.gmail.com with ESMTPSA id p19-20020a05600c1d9300b003942a244f39sm2898272wms.18.2022.06.08.02.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 02:59:33 -0700 (PDT) Message-ID: <36cc5e2b-b768-ce1c-fa30-72a932587289@redhat.com> Date: Wed, 8 Jun 2022 11:59:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-aio@kvack.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org, virtualization@lists.linux-foundation.org, Minchan Kim , Rafael Aquini References: <20220606204050.2625949-1-willy@infradead.org> <20220606204050.2625949-16-willy@infradead.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 15/20] balloon: Convert to migrate_folio In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D49AD120049 X-Stat-Signature: 3cjig8xacerz5eiqhd5b58s7hz68is83 X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HTgr1iTc; spf=none (imf29.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam08 X-HE-Tag: 1654682376-800915 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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@casper.infradead.org > > 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