From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 4C53C39FCAD for ; Tue, 7 Apr 2026 12:46:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775566019; cv=none; b=qgHLZ1jFDhi9AvAbEm8kr6uL1OoUJOmHkU5t2gWpwEpNeq+1fuoM7O7A9fEJTUgtyO1hWaL2w0b4E1DV8zHcbZnzSOyXcPrsNRqSUuJ/MIL3Wn90VOk31Lk/C3Bywh7C6+Pv9wmUYh5QOQ1LHmM5aO+k24yksXOWKWUx/TOIGIQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775566019; c=relaxed/simple; bh=Oia9SqZYN/FuRKrdOgGkOJ4u1epd7ZdGJwMoJIPV3Rg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ka1PCyDPBSXEUflNnJ5DFrCX3/nqLd6a+50Q8KPgg7Wg/hCJ4A1MXyjqPCVaQvg0x8GlVW9fj2qvwUQ9PKwUDO4SdInTmGsWReQWokq1OfyefnMttacUFcq3qPGwecGQETtyt0Pi/rGX/oLouGXcHlo6Ti0BnlB9qeIS7q9YJ9U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=IM0k/TZV; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="IM0k/TZV" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-488af9fdaa7so11680325e9.1 for ; Tue, 07 Apr 2026 05:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1775566017; x=1776170817; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=vbTQpF3+hPLIOL+yboKhhdmIl8i/2JZY5hAAOzxmhBI=; b=IM0k/TZVvgDChIHiNpXNqHDc428iVGm97eEOSQPFeNccmHgDV14BZORdOQETVEU4VM xDNWoai21ZMq1uIzkAVUBsSkaSknCHZ4YUhsdfNzsRfytSIzJWIqAMrbJqjFFOxfoP6m vaEeVLx2YOdJDB9iFanbua4ZGYzFSk5ska1JDMIZIf6BtgVmdmpmAZdeiuxAQPf41UQX sYeV1Hj9/NfCKVk2Zme1KKqx9hyypiCX+6JJ4ENSjV0cs/R/Kg4c1OgcG7O0nNy7xf4w sB7x2nBAdC5Zis3roYonqT1Gc3dUpbvzSYL9wZMIz45hIdlEcSQH7azw4G16UA+Ckpg6 UVnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775566017; x=1776170817; h=in-reply-to:content-transfer-encoding:content-disposition :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; bh=vbTQpF3+hPLIOL+yboKhhdmIl8i/2JZY5hAAOzxmhBI=; b=btLxX34tLfbCyjAYf+BkEuHXxrAYhrcORLVBlk0FT6PEuif/hrhniv2JTN+zmiG4CD q8toC7EiZp5ngeKe2cxgQMSqbumgqnx38HOZZDGQRMjZtUeHEbJbQkIlOHoS/cFRyF6o UoppFvSdI0Lxwuoxq+jFdydiaUZV8G7/nZc/IuCvwMkbahg/r7bl4o4kPWzcHHL1yM4I YlwwXgN9UXr6R1d1fGwYfSVL+lEvb4qpRlMp0URGz4Myn+57zFrDl5ofKf+QfAR+H1bL Gb1rG2q8YL7B7LgxOBC4x64gRWbGbsSpYrjK+Mig9p2FNeXb4gAByKCPr8D37m5MeDgm pfUA== X-Forwarded-Encrypted: i=1; AJvYcCVH4jnuolrOs3NPK9bk61QKAke1d4Bn86P58+1CXs06G5uG0C5ehfFloisazjq4ZYmH1Y2SJWJQk/0qmSA=@vger.kernel.org X-Gm-Message-State: AOJu0YxGnd94+uUljX6gN9TRUsWBkKJdeB3z2yAIhZefK1+lrOulMDyT VFbJ6gUtTh8a2IcFQILcO51dB21PXwR5rQrbzEoiHE+1iojz1zQOYBcqs3xBIvqpk50= X-Gm-Gg: AeBDieuU4vPjkTcVNIFRxrIN/vU+qCa++eYKPqrt5zSKe7EYxjx3nsSdFzcrIp7WYKY 8ernESTIKJJLJq9bv3UKU0PeXDRG3gUu7Co6e6gLm2waiud/XcHG8zDjccI1ecbODgXN6US0xyB X+QT//LS4AO3t6ErcHjppX4cekiRXZAdLgHeZMYThlEDmrBAkaxeKHVfGjUAllJ/VIujKFLT7hV LYavIANMbErbr0PV70RpKjaaJgRR3jjJzxOQ+tGEXXhU3kCqfa5I3WSTQx+g4V1/uGTk4g/qYSF ryVUffJyhwGFUbBxhSn8F/12U9TtcLmBE0iJOuOIG9s1jCFeWGuBqtn566/HujualOc5B47RQTs xUad+Gd+p7Y8DpBaXON+ZKEB74hiCcfhG/fYgP36slX8DeHRvTao9q4UoDfKb+zEXn/dDOJnzXj eG6ETrVWaMo3So2GOXwtBq70VWwmJbVfBrq5sP X-Received: by 2002:a05:600c:64cd:b0:487:1fbf:e0bb with SMTP id 5b1f17b1804b1-488996a1c9dmr247002615e9.6.1775566016576; Tue, 07 Apr 2026 05:46:56 -0700 (PDT) Received: from localhost (109-81-88-253.rct.o2.cz. [109.81.88.253]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48897fd7e2bsm178382765e9.2.2026.04.07.05.46.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2026 05:46:56 -0700 (PDT) Date: Tue, 7 Apr 2026 14:46:54 +0200 From: Michal Hocko To: Jianyue Wu Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hannes@cmpxchg.org, david@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, baohua@kernel.org, bhe@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: move folio LRU helpers out of swap Message-ID: References: <20260407110002.204755-1-wujianyue000@gmail.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: On Tue 07-04-26 20:31:40, Jianyue Wu wrote: > On 4/7/2026 7:20 PM, Michal Hocko wrote: > > > > All that big churn is really worth it? Are there any other reasons than > > "not so appropriate"? > > > > Really if this is not a part of a much bigger plan then NAK. > > Hi Michal, > > The intent here is to keep generic LRU/reclaim helpers separate from > swap-specific code paths. OK, but why do we want this and cause a lot of code churn to achiev that? > The LRU helpers are shared by both file and anonymous memory, whereas > swap.c is meant to host logic tied to swap devices and swap entries. > Placing LRU code there would blur the boundary between general reclaim > and swap, and make the code harder to follow. The code is harder to follow than it could be, no questions about that. But that alone is a rather weak argument to justify a lot of code move that cause a lot of conflicts. > Separately, I’ve been looking at routing zram’s swap-slot handling > through swap-owned hooks (e.g., swap_ops / swapon probing), which would > involve swapfile.c and swap.h. That’s likely orthogonal to this LRU > move, but it’s driven by the same goal of clarifying the swap boundary. Does that work benefits huge by this work? -- Michal Hocko SUSE Labs