From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (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 BCCFE23D291 for ; Mon, 8 Jun 2026 17:39:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780940388; cv=none; b=qrIJXEQMs5Jfp0vhsMYAyM15yV2bwaiwN/CKMMX5r+1YSUSJUDqRmF9SpPmEmzrv5NPUFGj0NM976a4Hh+iLJKIlk3mxjqWA/xgS+0dBmXzd+v9j5Fre/Ivlb9IwFR4BCc/Sa9iYjGlmx8J8gMSvzZqPptsq2ATZHHtXf4Zzg0Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780940388; c=relaxed/simple; bh=1m2hz1ys6DVs1E09IndlQLyoz5Rhmr7eVX2mxvd8U+0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qh382bgDPH9yP5R2kHATnHBrlRuifg6kqyxdFtVUckjML33o+Cw9jExWmjBxgQJWK2JPQHduEONRsfjCoCDEOZXirzH+Qz8xzg3LgdvfQTfsLbZAxKzx76CNtKZ7BWSa8ryh9rFnDKJY5zZfmvNilz5BcwiT9GCtJf3/mqzZFeI= 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=UUjZic9D; arc=none smtp.client-ip=91.218.175.185 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="UUjZic9D" Message-ID: <00cb36cb-e7df-4638-8137-504e27c5509b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780940382; 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=9yTj6Gbu49i3sY8rfakxka1MWJqqVniwSsgHpt4ReIM=; b=UUjZic9DHfyrCHdrXQmwJHWMcbj+tp7KYQvlZL8t+gZYovAAXCOKRjqxrVVeFmbcjzLoDr QEG386kqBSxW16pUfFqnnU2fPuQ9IgDZLXLwTy0Q45Zq6pHlareP/UFmbFu9JYxME3BZLV PQV606tjtw/vW7vHpuPkfINFJmtTW9U= Date: Mon, 8 Jun 2026 10:39:22 -0700 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: Shakeel Butt , Usama Arif Cc: Andrew Morton , riel@surriel.com, david@kernel.org, baohua@kernel.org, baoquan.he@linux.dev, chrisl@kernel.org, kasong@tencent.com, linux-mm@kvack.org, hannes@cmpxchg.org, 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: JP Kobryn In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 6/8/26 9:06 AM, Shakeel Butt wrote: > On Mon, Jun 08, 2026 at 07:32:42AM -0700, 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. >> >> - 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. >> >> This is a direct continuation of the cleanup started in commit >> 1aa43598c03b ("mm: remove unnecessary calls to lru_add_drain") which >> removed the equivalent drain from free_pages_and_swap_cache() with >> the same rationale. A detailed reasoning for this is present in [1]. >> >> Remove both drains. >> >> [1] https://lore.kernel.org/all/dca2824e8e88e826c6b260a831d79089b5b9c79d.camel@surriel.com/T/#u >> >> Signed-off-by: Usama Arif > > Acked-by: Shakeel Butt > > Thanks for pushing this. JP was also looking into LRU lock contention sources. > Particularly we lack visibiluty into the lru_add_drain_all() callers. The idea > was to add tracepoints to tracks such callers. (Just nudging you towards it :P) Yup, I'll send a patch for that one.