From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f44.google.com (mail-yx1-f44.google.com [74.125.224.44]) (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 50E6D430CC6 for ; Mon, 24 Aug 2026 13:52:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787579570; cv=none; b=Hfw330W3aQQcYyliHcvwY1JVQUqpL8OqA/OkLgmYXkbPaIg9IlPkXpaNuDa8YyCh4JuMR2bH+E7zT814N35xV/F1cYa/0gIds6yGB7vOlEZ644B/dty5CzJWy5zbQIKnsSqOzZ9/MmD19aW7NquJJbQR8S6nUrqajqk2vMrdMPo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787579570; c=relaxed/simple; bh=INQpY4vkmtPsJDoCs8IyTHaF6Ew7wSWtqA9unZfAs40=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=YHrW0j4MQ3ds73NYUVYOH9lvXJ50s8XyuK6Ib63RTNuMkQOiGxWFDDYNRVETUSa10WwF7rYimeSGkKbn1mgGdgGfv/JS22j7rClpUqej/Bk93jjsFFv18hvDdy3Aa5tSH/fFThFJzJckmCq+JQkWClySUu3e8grVIIoywbfHdSM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=hu6X3jGD; arc=none smtp.client-ip=74.125.224.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="hu6X3jGD" Received: by mail-yx1-f44.google.com with SMTP id 956f58d0204a3-66ceaade3f1so2138518d50.1 for ; Mon, 24 Aug 2026 06:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1787579568; x=1788184368; darn=vger.kernel.org; h=content-type:mime-version:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=n94V7wbjjjBLybhmkw6p8j8STOH0bCJCKxuuQhNVBOI=; b=hu6X3jGDHFD05LuNeJDhlU+vZjMv+Tu2gevXiip4LPrM1pwMF9fjU48iE3OeoCqad0 sDJg1f9GIkJYdmNuP0hlr3AH5D60sX56d9LSbeDKqG/SVyR21/who9KZKZla2z90wQY6 zD4Mk6ovSgUncPfhddvClr1Y2hX0t3HrSdB4ksSrawyN5AB4ah4U9qbr2kXCVmpe44TA bHJGzyB4wN3le1XTBP/9jQrQK4k3iQw1rIie37nFAGiT02/kwQgl2NWcxaFcc7TvEl7p iJD+7cEGcAzuIizJF44H8m69FlNALUnW/Ys1o2KYXs+PNy+0ZKuNzEvRf9qcbE2Lx3kv waww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787579568; x=1788184368; h=content-type:mime-version:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=n94V7wbjjjBLybhmkw6p8j8STOH0bCJCKxuuQhNVBOI=; b=Tj5vtJhTX7u2t6VkIV02yA4GaTUiH9ZbpNcFrh5a8QEzfWThiyaFDojarWkRRyVMg8 gmPtN5sCf9GUO24Zx1Bd20bVfvTMvf8DgUb2jNkePPN/9+pptTrgoPqGCEEPvE50UftH iMPJXv9bbgbgInwX1oYRf9fYCPiTsi9XugH5/W+rcXDJh4CzBHgyj2Fw0x2NX8uXCld7 Yfkaf3WiB7sYbM/n2t+pTzO34oFLYvRFCuK37m1lAa0kTU++lR2XSPRrA8SSHghi0Vvf KjJG2VMeNJCFNTk0lTi+wXYssy8FpHQvE23P8vn7tFSIe5bNS9WQc6A3dKXOAIeAiHgV Nwuw== X-Forwarded-Encrypted: i=1; AHgh+RrnUAIqiIQmI/7ziYRAc2ZSe4xnlhu3fwv3YlgtGg80a6JXCCgCzCxHKTm3F5gOJ1N605Q/1bfHiR69ZVg=@vger.kernel.org X-Gm-Message-State: AFuF++kvkCZA13Gfo3sUnVXqZ2KS7cFVwBLJowWqcN2BEkzRbp6ggVb4 5Zob/BFbA9PR1RWVD5BtP2tuMrxgjijy9ygnJJhTWFb+lzEnoH2XhsSf8OpSXOLfHQ== X-Gm-Gg: AR+sD12e/zzH35cCYPgJ+5abDp1+cIzYdsv5MtD4mJYhtqTF7fgouQ43Hm7TqY+7121 7QafYOoPnB+jPdtJgVonN8JR8WBOSdHW2w+v0Nbk5Uv+m9ajbpI4Qoo69juUKX6rq8TX6mxjZWm xL8bMFWvQpEsg1dHwajDcfgRyIdaEqyVABghLOnnMsNWbQgf4bPFjbEOkBiuYoCsmqZXedtd5Ry dyLaH7jEDPDWFcvPul9ab+/0NRtlb8/QYlCaP1DJePBkE8O38xMmVGIMXGTiixFskvP1w1Gqm2H 9mb8R5vMrnTOWmjw5Nb7h4+EzDsac8cmJniY/ykFbHrWS/VHkYl2mt2aanIg/HLhHBKdmxCC4fk Dg+XzjWqRJThDv9LwULDM1l3oIbIL2F3ulvdsD5bsp/OmmGl8rNKNzUxWSxr3GanPAQCGu6tMBV d2GmB+zT4urdP4ycbXpuEG3kTaglQGyQ+hhdNSP1v2h0Hg5lAeEvnb8G0B6o1aNRqe92GmlqDYQ ZY4uV/UKUsp0QfqMNmsM+UA9SSatm7Pyi3BJNNPsvPASPqOfJwB87R0E7cdmVYlK5TZ6Rw= X-Received: by 2002:a53:cdcf:0:b0:667:b314:aea4 with SMTP id 956f58d0204a3-66ce4a56db4mr7162361d50.16.1787579567501; Mon, 24 Aug 2026 06:52:47 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-66cf4624f47sm3724257d50.4.2026.08.24.06.52.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 06:52:46 -0700 (PDT) Date: Mon, 24 Aug 2026 06:52:41 -0700 (PDT) From: Hugh Dickins To: Andrew Morton cc: Ackerley Tng , Alexander Viro , Baolin Wang , Barry Song , Binbin Wu , Christian Brauner , Christoph Hellwig , Christoph Lameter , Claudio Imbrenda , David Hildenbrand , JP Kobryn , Jan Kara , Jens Axboe , Johannes Weiner , Kairui Song , Kiryl Shutsemau , Lance Yang , Leonardo Bras , Lorenzo Stoakes , Marcelo Tosatti , Matthew Wilcox , Mel Gorman , Miaohe Lin , Michal Hocko , Minchan Kim , Muchun Song , Oscar Salvador , Peter Zijlstra , Qi Zheng , Rik van Riel , Sebastian Andrzej Siewior , Shakeel Butt , Suren Baghdasaryan , Vlastimil Babka , Yang Shi , Yu Zhao , Zach O'Keefe , Zi Yan , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 01/25] mm/fbatch: remove !CONFIG_SMP special case of folio_activate() In-Reply-To: <14a16945-529b-8bc0-ab38-3ea97e54e223@google.com> Message-ID: <3f18ab7d-c12a-d2a3-4d3e-f9908f94f27d@google.com> References: <14a16945-529b-8bc0-ab38-3ea97e54e223@google.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=US-ASCII 3.0 commit eb709b0d062e ("mm: batch activate_page() to reduce lock contention") brought in an ifdef CONFIG_SMP around activate batching: https://lore.kernel.org/linux-mm/20100805140755.501af8a7.akpm@linux-foundation.org/ shows a sensitivity to bloat that day, not any incompatibility with UP. No other batching here has a UP alternative, and it's a bit confusing: simplify mm/folio.c a little by removing it now. Certainly we can reduce UP bloat (and/or 32-bit bloat) by, say, lowering FOLIO_BATCH_SIZE from 31: traditionally 16, 14, 15, then raised to 31 by 6.9 commit 9cecde80aae0 ("mm: increase folio batch size"); or by giving just the static per-cpu folio batches a type of their own with a smaller array size on UP (1? or a little batching worthwhile even on UP?). But not right now, it's orthogonal to this series. And I suspect that the old ifdef led to lru_activate being placed last, whereas it's usually the second most popular fbatch: move it there, to match cpu_needs_drain() comment "Check these in order of likelihood that they're not zero". Signed-off-by: Hugh Dickins --- mm/folio.c | 40 ++++++---------------------------------- 1 file changed, 6 insertions(+), 34 deletions(-) diff --git a/mm/folio.c b/mm/folio.c index d2937600cf72..62b96c9ce19e 100644 --- a/mm/folio.c +++ b/mm/folio.c @@ -47,12 +47,10 @@ struct cpu_fbatches { */ local_lock_t lock; struct folio_batch lru_add; + struct folio_batch lru_activate; struct folio_batch lru_deactivate_file; struct folio_batch lru_deactivate; struct folio_batch lru_lazyfree; -#ifdef CONFIG_SMP - struct folio_batch lru_activate; -#endif /* Protecting the following batches which require disabling interrupts */ local_lock_t lock_irq; struct folio_batch lru_move_tail; @@ -349,15 +347,6 @@ static void lru_activate(struct lruvec *lruvec, struct folio *folio) count_memcg_events(lruvec_memcg(lruvec), PGACTIVATE, nr_pages); } -#ifdef CONFIG_SMP -static void folio_activate_drain(int cpu) -{ - struct folio_batch *fbatch = &per_cpu(cpu_fbatches.lru_activate, cpu); - - if (folio_batch_count(fbatch)) - folio_batch_move_lru(fbatch, lru_activate); -} - void folio_activate(struct folio *folio) { if (folio_test_active(folio) || folio_test_unevictable(folio) || @@ -367,25 +356,6 @@ void folio_activate(struct folio *folio) folio_batch_add_and_move(folio, lru_activate); } -#else -static inline void folio_activate_drain(int cpu) -{ -} - -void folio_activate(struct folio *folio) -{ - struct lruvec *lruvec; - - if (!folio_test_clear_lru(folio)) - return; - - lruvec = folio_lruvec_lock_irq(folio); - lru_activate(lruvec, folio); - lruvec_unlock_irq(lruvec); - folio_set_lru(folio); -} -#endif - static void __lru_cache_activate_folio(struct folio *folio) { struct folio_batch *fbatch; @@ -694,6 +664,10 @@ void lru_add_drain_cpu(int cpu) trace_mm_lru_add_drain_tp(cpu, nr_folios); } + fbatch = &fbatches->lru_activate; + if (folio_batch_count(fbatch)) + folio_batch_move_lru(fbatch, lru_activate); + fbatch = &fbatches->lru_move_tail; /* Disabling interrupts below acts as a compiler barrier. */ if (data_race(folio_batch_count(fbatch))) { @@ -716,8 +690,6 @@ void lru_add_drain_cpu(int cpu) fbatch = &fbatches->lru_lazyfree; if (folio_batch_count(fbatch)) folio_batch_move_lru(fbatch, lru_lazyfree); - - folio_activate_drain(cpu); } /** @@ -825,11 +797,11 @@ static bool cpu_needs_drain(unsigned int cpu) /* Check these in order of likelihood that they're not zero */ return data_race(folio_batch_count(&fbatches->lru_add) || + folio_batch_count(&fbatches->lru_activate) || folio_batch_count(&fbatches->lru_move_tail) || folio_batch_count(&fbatches->lru_deactivate_file) || folio_batch_count(&fbatches->lru_deactivate) || folio_batch_count(&fbatches->lru_lazyfree) || - folio_batch_count(&fbatches->lru_activate) || need_mlock_drain(cpu)) || has_bh_in_lru(cpu, NULL); } -- 2.51.0