From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2AC513074AF for ; Mon, 10 Nov 2025 11:05:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762772702; cv=none; b=BeB/1NXEARRjBDqg0G+du3aU13Twwg2bh0tN9epNa4+weeXdFZerA8Cwi9ZG0xM/3V6G60V1uThcOQZdGq4+kVSHIAOw1c+Imw2wN3aQTJjJjcHsDdeJ+Q+N9YurBvJOJGJesDp0bfpC11Qgm5G8WsSJiJdR3BhzT5wg9qiOlZU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762772702; c=relaxed/simple; bh=57vcXoVaGnG9l4Hdh9tDUE5rwfPZ24UgvbT3aVj/BUk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=UtQ+tHYdRI7g648ClCu0DvNvscAxh55rpv1yPbysnIlinf4HyM2h3glkXZ3WRIgxbKXN4/zS7gAjTAZ+Mawjfpcnolj3QcdwezFER4G+kWB47vf1zBqFwNyr3QgoA/O0KiSFi29M5iHmQYKsrdfDJpqDdw12T0qr/1sjqieEyH4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sa6AQQ73; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sa6AQQ73" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6140C19421 for ; Mon, 10 Nov 2025 11:05:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762772701; bh=57vcXoVaGnG9l4Hdh9tDUE5rwfPZ24UgvbT3aVj/BUk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=sa6AQQ73O01w64nwho5tib1IxlyUdIJGtdtZ9Hkgxafn61iopBLbXLDF1Ba5V2i27 WD6YFYVerjMnAIO9/muIJYDdpv8clNUqhwoewQ/kI6xBSZ7jVC6JHroti+9tXdEs20 5EKZAMf9l+SFPX7I9+FCSHrvUm+bOAkz1wYS9nveGAjwkbxnr4Nd7GtPj5xjzuo5O4 Fc7gKbOMrlamMfMeSGiNycyH/4IkhNBrCVvNpqk+BQzuNmMhCTvf5IxMmj7iK+EaLs ETWg/vuyz4jZTP7O28TnvbQhzcLZpoWBPH2g2qFYB1KLl4zsm3zT9ooSaICIThBSgK PLzO/EzPnjooQ== Received: by mail-yx1-f49.google.com with SMTP id 956f58d0204a3-63fc72db706so2607749d50.2 for ; Mon, 10 Nov 2025 03:05:01 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXR81/PW1Ljsb7eJ5SlMHESg62PlVPCWokhGC8+LJ2X2Bjq9InzFZh1t1WBu439BH0zVm9ipQAGPgHc2EY=@vger.kernel.org X-Gm-Message-State: AOJu0YxEirS91mMnYt6FMxkD6/YSyf2ZyGiQ+qniIUTZWuXytN/Geo5e lXfVnY+hYybcyy1obUfrTrzJHVx6+EtexJIoJ94DjiBeH3b75D3lBspOTn8lBaUil9VxzDuy4x+ olhPJUzYZkoE41i57hG7sHEz0g1oIsahwnQRaZPXLgA== X-Google-Smtp-Source: AGHT+IGb5xn+sWB6zhZvawlKpKaY52jteK/NuAWw2b6kNJUT3KOwS3xUtwezxnsh77APdSOaFVEz79TEZy9y4Ini9II= X-Received: by 2002:a05:690e:2598:b0:63f:a089:ad11 with SMTP id 956f58d0204a3-640d45e57f4mr5199456d50.47.1762772699777; Mon, 10 Nov 2025 03:04:59 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <5b60f6e8-7eab-4518-808a-b34331662da5@lucifer.local> In-Reply-To: <5b60f6e8-7eab-4518-808a-b34331662da5@lucifer.local> From: Chris Li Date: Mon, 10 Nov 2025 03:04:48 -0800 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bl_ugrcb7Xqm2Eobi_WepJs_DP4Kj2CRqbuSy5_pOEO8kL68WELcSVKV30 Message-ID: Subject: Re: [PATCH v2 00/16] mm: remove is_swap_[pte, pmd]() + non-swap entries, introduce leaf entries To: Lorenzo Stoakes Cc: Andrew Morton , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , David Hildenbrand , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Sven Schnelle , Peter Xu , Alexander Viro , Christian Brauner , Jan Kara , Arnd Bergmann , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Muchun Song , Oscar Salvador , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Axel Rasmussen , Yuanchu Xie , Wei Xu , Kemeng Shi , Kairui Song , Nhat Pham , Baoquan He , SeongJae Park , Matthew Wilcox , Jason Gunthorpe , Leon Romanovsky , Xu Xin , Chengming Zhou , Jann Horn , Miaohe Lin , Naoya Horiguchi , Pedro Falcato , Pasha Tatashin , Rik van Riel , Harry Yoo , Hugh Dickins , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, damon@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2025 at 2:18=E2=80=AFAM Lorenzo Stoakes wrote: > > On Sun, Nov 09, 2025 at 11:32:09PM -0800, Chris Li wrote: > > Hi Lorenzo, > > > > Sorry I was late to the party. Can you clarify that you intend to > > remove swp_entry_t completely to softleaf_t? > > I think for the traditional usage of the swp_entry_t, which is made up > > of swap device type and swap device offset. Can we please keep the > > swp_entry_t for the traditional swap system usage? The mix type can > > stay in softleaf_t in the pte level. > > Ultimately it doesn't really matter - if we do entirely eliminate > swp_entry_t, the type that we are left with for genuine swap entries will > be _identical_ to swp_entry_t. As in bit-by-bit identical. In that case you might just as well leave it as swp_entry_t for the _actual_ swap code. > > But I did think perhaps we could maintain this type explicitly for the > _actual_ swap code. Exactly. Please do consider impact the actual swap > > I kind of wish the swap system could still use swp_entry_t. At least I > > don't see any complete reason to massively rename all the swap system > > code if we already know the entry is the limited meaning of swap entry > > (device + offset). > > Well the reason would be because we are trying to keep things consistent > and viewing a swap entry as merely being one of the modes of a softleaf. Your reason applies to the multi-personality non-present pte entries. I am fine with those as softleaf. However the reasoning does not apply to the swap entry where we already know it is for actual swap. The multi-personality does not apply there. I see no conflict with the swp_entry type there. I argue that it is even cleaner that the swap codes only refer to those as swp_entry rather than softleaf because there is no possibility that the swap entry has multi-personality. > However I am empathetic to not wanting to create _entirely_ unnecessary > churn here. > > I will actively keep you in the loop on follow up series and obviously wi= ll > absolutely take your opinion seriously on this. Thank you for your consideration. > > I think this series overall hugely improves clarity and additionally avoi= ds > a bunch of unnecessary, duplicative logic that previously was required, s= o > is well worth the slightly-annoying-churn cost here. > > But when it comes to the swap code itself I will try to avoid any > unnecessary noise. Ack. > One thing we were considering (discussions on previous iteration of serie= s) > was to have a union of different softleaf types - one of which could simp= ly > be swp_entry_t, meaning we get the best of both worlds, or at least > absolutely minimal changes. If you have a patch I would take a look and comment on it. > > Timing is not great either. We have the swap table phase II on review > > now. There is also phase III and phase IV on the backlog pipeline. All > > this renaming can create unnecessary conflicts. I am pleading please > > reduce the renaming in the swap system code for now until we can > > figure out what is the impact to the rest of the swap table series, > > which is the heavy lifting for swap right now. I want to draw a line > > in the sand that, on the PTE entry side, having multiple meanings, we > > can call it softleaft_t whatever. If we know it is the traditional > > swap entry meaning. Keep it swp_entry_t for now until we figure out > > the real impact. > > I really do empathise, having dealt with multiple conflicts and races in > series, however I don't think it's really sensible to delay one series > based on unmerged follow ups. If you leave the actual swap entry (single personality) alone, I think we can deal with the merge conflicts. > So this series will proceed as it is. Please clarify the "proceed as it is" regarding the actual swap code. I hope you mean you are continuing your series, maybe with modifications also consider my feedback. After all, you just say " But I did think perhaps we could maintain this type explicitly for the _actual_ swap code." > However I'm more than happy to help resolve conflicts - if you want to se= nd > me any of these series off list etc. I can rebase to mm-new myself if > that'd be helpful? As I said above, leaving the actual swap code alone is more helpful and I consider it cleaner as well. We can also look into incremental change on your V2 to crave out the swap code. > > > > > Does this renaming have any behavior change in the produced machine cod= e? > > It shouldn't result in any meaningful change no. That is actually the reason to give the swap table change more priority. Just saying. Chris