From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33C9047D476 for ; Wed, 5 Aug 2026 15:54:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785945285; cv=none; b=OjoH29sNehzeK8DFwMnd8/qk1N93J7psQcFQmU1IuUe8hUZ0sSECETH1+3DWKZR1aCowz0p500iCfPqQ1fHcSLXuPRGuHKdHRl0gfExz56+yyZkAYPoDF9SNFiE73vvOnKN+X0LUhGoL1qbuPzttpYh7b7oLtmWXAU4zut44x+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785945285; c=relaxed/simple; bh=rZdAOZRrlWJDlWCV6+LShKvadlRsq30zPunO2V/Grcc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qx18tdodL0niE3gxuyMc1fsBxIFZACaYImZGiRpNELNbMF7cD8P8WEpzycvhcYEAphsf0rJMKzV/x8sAU0dpY/ibvbFl+V+DD4IDjFdaaXyATlZe0X3ldgBhAz4HXbmPRTZIUzilQUH1JpGTEUng91lVMpOxjDOt9hQvj305NqY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=fldv0WhK; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fldv0WhK" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2cf27856f9cso14694895ad.2 for ; Wed, 05 Aug 2026 08:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785945283; x=1786550083; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=SiDL1RzWS9KxGO4Do/pBrGufTQ4ZH9KDIw9xKfe1s38=; b=fldv0WhKjLPQHzjJ+A8uDyjAi5ZQrt+aoSeqmyozfvny2K6jp4H/XBq4iTfHJ8LhX6 9wXJZROGfbEdrDcZZS6mguwnxgUKFkgdHHS/pL0w8G4x+HcDbLcll/85WrP/jOvLsJux aTbnNO4uOINQE2LlXBBwVGo09YZdLePaXoRQ4DwdSv2ehffA93U6mD6BRuoIj9wJcgUB SdCpio78d4Yoaq94c8Wcx3KDItu/Lrrd1Z1wvjLN6p2De5z684VmJb0B4V4dL+soRlY2 KIL6/NjbtK8LaJq0JKtPgUNxNsVo0uuSnAwHMUqM0xi2bEA7JfAWUQ/xAa+s//2BcyrE WOBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785945283; x=1786550083; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=SiDL1RzWS9KxGO4Do/pBrGufTQ4ZH9KDIw9xKfe1s38=; b=Ftx7U8Ft5Emw/PfKSWwtHmC10nqXbG0Ny6jLxC8o7PMTIsr5a4BfLXFrdvpfTW2cPC fqQ9U8Mzkn0STNvZmGpqf3Q8QfcaFDZ5mn+bcgozggoPm7QXJr/HCcx9F/lXnynayjXB QtkMbvnzCy2pTOPL3QTEJc9IJ7Q3Dd4q/ysBOqY3LL6XjkuPDSBhfBadIQshfObS6UL6 +fu0hgEY7R2Q1DyhqLfneRxF+8CFqPETghtQKvl9v7ujXBE2Odoj3e44FNDUh8qDDmhs iKXl3DNFAjLnwovhFFfZlPVX4fHIXLACYlhPL5CDwmD/ncgGh/MwmN2CoC5XATBBsomj EDmg== X-Forwarded-Encrypted: i=1; AHgh+RqvBcAbv+KQx7WcHNf2IVDL2roCll4zYiV/4urEcBrCoC+APU5sma62bZCPbw70y7gCtnis2oNuHaWv+Gw=@vger.kernel.org X-Gm-Message-State: AOJu0YzvRz8u2XPrdqApxuFS5bMrOKvvMfvsYcccogG8JZgEnD9AYgHd OVjxCZ2nwS/hRLZm1CKlJFI1nyX5mFuFB4zJTEb/zVch9OfxFzXGH3lk X-Gm-Gg: AR+sD12YXWXP6dRmxwRkJZl3sx++XN0uckxaxJQH2gf7Z13o3HA9+ZCnmHFtK1xL3wk zZvY87dAm7QSdUx9bq8PsA2u6Td2wSkm8L4z6GtGuhM5FS6Dzv16bYeGLA2abEk6qCbt4hStt9W ehyMbDo233US6fGxHDB4XT1h+FWrR4oG0zb0Rb2BPK3uFc73ZSkNT2y8Ku0sX68+LCc9VfmhZXM k9VqhB32/zGSSxvNloKrox8RFhVMv3qg9HiEgoMlYJOH+CBWUt50V87aGYjcWB57REhd1B0XOXR E5Zae4qeGGbkm5TVriCiRus4KmosmjkUXtjfBLU8BJI8GXbrvbJWjxK0ceguOWHPqvlmxwAanTU H9I3z8EkTeSxUj0Mfdv9HAAVBgWY1FVfPe3EYjhWDO851IBbfXfMaBCn3/tlEyryuge0WkyCPH0 acQav/uniyj4giMarouzNP7WFBvXRNsi+6qtMR84P3bcofTAS36ixcDJb8dsMaAjWzoV474icYm gyb4j5TgjsEiCjCZg6I6mQU X-Received: by 2002:a17:903:3201:b0:2d0:401c:2ebb with SMTP id d9443c01a7336-2d0ca7125cemr99090365ad.4.1785945283158; Wed, 05 Aug 2026 08:54:43 -0700 (PDT) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d0aa4ba225sm18570705ad.61.2026.08.05.08.54.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 08:54:42 -0700 (PDT) Date: Wed, 5 Aug 2026 23:54:34 +0800 From: Kairui Song To: Zi Yan Cc: Shivam Kalra , Kairui Song , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Baolin Wang , "Liam R. Howlett" , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Shuah Khan , Nico Pache , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 0/3] mm: support splitting mappingless swapcache folios Message-ID: References: <20260805-b4-mappingless-swapcache-v1-0-b1d78ba257ca@zohomail.in> <590B3189-5B66-4ECB-84CD-7B7EF18C0E54@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <590B3189-5B66-4ECB-84CD-7B7EF18C0E54@nvidia.com> On Wed, Aug 05, 2026 at 08:03:33AM +0800, Zi Yan wrote: > On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote: > > > Large shmem folios lose their address-space mapping when they are written > > to swap, but remain valid members of the swap cache. Folios read from swap > > but not yet associated with an anon_vma can have the same mappingless > > swapcache state. folio_check_splittable() currently mistakes both cases for > > truncation and rejects the split with -EBUSY. > > > > Implement the longstanding TODO for this state. Allow mappingless > > swapcache folios to use the existing uniform order-0 swapcache split path, > > while continuing to reject truly truncated folios and unsupported > > higher-order or non-uniform swapcache splits. > > Thank you for your patches. > > As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”), > we might not need to implement this split. I will let Kairui to decide > how we should deal with this patchset. > > [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/ Thanks for the CC, this is actually not hard to implement as shown by Shivam, I just found the code more and more hard to follow and fragile as we add more logic to it. And we don't have to reject higher order split either which can be seen easily if the code is cleaner. Personally I think doing some cleanup first is better, I haven't post any code as right now there doesn't seem to be much user of this. It will be needed if more clean THP swapcache begin to show up due to things like THP readahead for swap, which isn't here yet. I think I can send an RFC tomorrow just for reference. I'm fine if we prefer to remove that TODO using this smaller change first :)