From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (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 9FFFE38F63D for ; Tue, 9 Jun 2026 09:30:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780997406; cv=none; b=kXOT5T/1HaGcQUwfBX3P7rwZZ72oaASAzh4Y/HHB6nqzWw8Qym5lYpU0orudPQ94eIGg+6ghPy88/ja17+4yEgVJYuFAjAPzQj0NN01h0oK8ECGLFnYc9KB9+KJXQZDukUJBd/ATL5SI67+zPMJM1zKfYFS9xuBdDa3MANSAkwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780997406; c=relaxed/simple; bh=DGzw7RJjKVE1ot9WrYhZiKuZQWP8sjovAvARQc2k/uI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=poOSbG65OI75f0H6TALkj2YPM6nJjdk5ruFtkH92xRCQ37pH70C2PC1GPK3fSyuyBEZ9Fj1PeE8aEOKhenLH6YJ3WQgSjJY2MUqnfgBH48vIkzjGn3HlO3tktdw24E6lpOw3c3wE6NEZ0IgMEQUuiQ4IYbC+c0/1jfh2+D8/66w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=X3PZat8M; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="X3PZat8M" Message-ID: <50c03b64-1809-4000-88dd-ab147ddc6620@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780997402; 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=qgCcb7AhIQHYCoo8iDRMB/0s0Gf7iyuIsikHPn5X6m8=; b=X3PZat8M7hFldYur1Ma629htXlwfI6xa08IXWGJwEg4G0ZQIxm4Ol9cgTxY1mHqFGB8Vv2 hiskl2bnYOWG4d6ZimWRu4D0dVDvQK0/j0vfuGZoBBdCcGQZ0bB9zQQbkQ9k4Dzr/RGR6G ZrP8NwLFC8WmsOgbGUyuxoyHP2RAtSc= Date: Tue, 9 Jun 2026 10:29:53 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] mm/swap_state: remove unnecessary lru_add_drain() from readahead To: Barry Song Cc: Andrew Morton , riel@surriel.com, david@kernel.org, baoquan.he@linux.dev, chrisl@kernel.org, kasong@tencent.com, linux-mm@kvack.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, nphamcs@gmail.com, shikemeng@huaweicloud.com, youngjun.park@lge.com, linux-kernel@vger.kernel.org, kernel-team@meta.com References: <20260608143242.2869392-1-usama.arif@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 09/06/2026 09:01, Barry Song wrote: > On Mon, Jun 8, 2026 at 10:33 PM Usama Arif wrote: >> >> swap_cluster_readahead() and swap_vma_readahead() end the readahead >> loop with an explicit lru_add_drain() call. That drain is a leftover >> from 2.6.12 era code and serves no functional purpose for the callers: >> >> - do_swap_page() ignores LRU residency for the readahead folios; >> it only needs the target folio it called swapin_readahead() for, >> and if the write-fault path needs the target folio on the LRU to count >> references accurately, it runs its own lru_add_drain() at the >> wp_can_reuse_anon_folio() and do_swap_page() sites. > > right. as i can see the below in do_swap_page(): > > /* > * If we want to map a page that's in the swapcache writable, we > * have to detect via the refcount if we're really the exclusive > * owner. Try removing the extra reference from the local LRU > * caches if required. > */ > if ((vmf->flags & FAULT_FLAG_WRITE) && > !folio_test_ksm(folio) && !folio_test_lru(folio)) > lru_add_drain(); > > and the below in wp_can_reuse_anon_folio(): > > if (!folio_test_lru(folio)) > /* > * We cannot easily detect+handle references from > * remote LRU caches or references to LRU folios. > */ > lru_add_drain(); > >> >> - shmem_swapin_cluster() immediately locks the returned folio, waits >> for writeback, then operates on it - LRU residency of either the target >> or the readahead folios is irrelevant. >> >> - try_to_unuse() likewise locks the folio and calls unuse_pte() without >> depending on LRU presence. >> >> Folios newly added to the swap cache by the readahead loop sit in >> the per-CPU LRU folio_batch and will be drained naturally as the >> batch fills (FOLIO_BATCH_SIZE),by the next reclaim/compaction >> lru_add_drain_all() and so on. The unconditional drain only >> synchronously flushes a partial batch and forces contention on >> lruvec_lock. >> >> On a 176-CPU production host running a memory-pressured workload, this >> path was observed to call folio_batch_move_lru() from >> swap_cluster_readahead() ~28K/min, a very large source of LRU lock >> traffic. >> > > Do we see a workload improvement? If yes, can we put the data? > Hello Barry! So lru lock contention is a source of issue in the meta fleet. This problem was specifically seen when I ran `perf lock contention -a -b` in production on a workload that has a really big anon heap and heavy swap activity. When I tried to trace with bpftrace who was the biggest consumer, it was readahead. It is easy to run perf and bpftrace on prod on this specific workload, but more difficult to flash a new kernel and see results. The easiest would be when kernel upgrade happens and this patch lands to see the difference and I can report back. Thanks, Usama > Thanks > Barry