From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (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 D8E9413C9C4 for ; Fri, 12 Jun 2026 01:08:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781226500; cv=none; b=nvdXPIfX1z5lOImVz6pcOmYzzi/Qh16UBbbg8gxIq595+FTlIQvyjui5VMUwYE8nD5A06OYa3AipsvozXsylXdRG/zL8eAC82Q8n59lX0D+PTxwcXJeJdcHRBI11Z9MQb3o0FD2y/2cH5yxWa69l4WN7kjt2OG5czG8s99IkEyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781226500; c=relaxed/simple; bh=5E82syaBY/upZzszKx76qzzpWVGo9R4rUHOQTlbKsjk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QFJdFcneOmVw6fj0RBd4++XgTrOlss4Yqe4xH7KRyunxdfamRnlzm708aMCbJXsLKTHCHJnKHS0yafFvwEYfcCqSJk6qajvhQs0CItNK8dJdmhWWEid0jBCl2SDUVIFnoe5CcKGySfIjv+03LDvualfeLWo6JuJ25W0XJdrDAjw= 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=l6fVwl9E; arc=none smtp.client-ip=95.215.58.183 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="l6fVwl9E" Date: Fri, 12 Jun 2026 09:08:09 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781226496; 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: in-reply-to:in-reply-to:references:references; bh=ZGr2v2BJyY5UICB7KiBteFIFz1E2P9OucbubOQfFQm0=; b=l6fVwl9Ey051O4rVxfWBe+5o8epL5Px2k2IEkV9ILwV5bRkeWeue5g/nsNo6wq+3b9qbg8 KwoEnEdJR07eKzDr4iBOcZbRsywGRzi6f2LRJo1zTZ+Gaj0U5KDtao8VLtQ+Cc4ZBc6nHG d8j1FORR+1dxgHgQgF7JC90AOB0T8II= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Baoquan He To: Shakeel Butt Cc: "Barry Song (Xiaomi)" , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@kernel.org, ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, youngjun.park@lge.com, jp.kobryn@linux.dev, usama.arif@linux.dev Subject: Re: [RFC PATCH 1/3] mm: avoid unnecessary lru drain for wp_can_reuse_anon_folio() Message-ID: References: <20260611105124.98668-1-baohua@kernel.org> <20260611105124.98668-2-baohua@kernel.org> 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 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT On 06/11/26 at 11:17am, Shakeel Butt wrote: > On Thu, Jun 11, 2026 at 11:09:43AM -0700, Shakeel Butt wrote: > > On Thu, Jun 11, 2026 at 06:51:22PM +0800, Barry Song (Xiaomi) wrote: > > > We always unconditionally drain the LRU before retrying anon folio > > > reuse in wp_can_reuse_anon_folio(). Instead, assume !LRU anon folios > > > are in lru_cache, and use the refcount to avoid many unnecessary LRU > > > drains. > > > > > > Signed-off-by: Barry Song (Xiaomi) > > > --- > > > mm/memory.c | 8 +++++++- > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/memory.c b/mm/memory.c > > > index 56be920c56d7..487a34377a7b 100644 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -4193,12 +4193,18 @@ static bool wp_can_reuse_anon_folio(struct folio *folio, > > > */ > > > if (folio_test_ksm(folio) || folio_ref_count(folio) > 3) > > > return false; > > > - if (!folio_test_lru(folio)) > > > + if (!folio_test_lru(folio)) { > > > + /* > > > + * Assume folio is on lru_cache and holds a cache reference. > > > + */ > > > + if (folio_ref_count(folio) > 2 + folio_test_swapcache(folio)) > > > + return false; > > > > In your experiments, how much amount of drains were reduced due to this specific > > check? > > > > I wonder if that data can motivate to introduce lru_add_drain_folio(folio) which > > only drains if the given folio is in the local lru_add cache. > > Actually if we can peek into lru_add cache and folio_ref_count(folio) is exactly > equal to (2 + folio_test_swapcache(folio)) and folio is not on LRU then we can > just reuse folio if it is in lru_add cache without draining, right? Sounds more reasonable if we can only touch the wanted folio if it exists in pvec. Believe it can improve efficiency more than the current patch. > > > > > > /* > > > * We cannot easily detect+handle references from > > > * remote LRU caches or references to LRU folios. > > > */ > > > lru_add_drain(); > > > + } > > > if (folio_ref_count(folio) > 1 + folio_test_swapcache(folio)) > > > return false; > > > if (!folio_trylock(folio)) > > > -- > > > 2.39.3 (Apple Git-146) > > >