From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.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 A34D622FE11 for ; Fri, 14 Nov 2025 02:23:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763087039; cv=none; b=jSr1nb0kbUpq/Pfvz0+Ihchr7nvl8mqFeXdMcFwwynoV+llXhAL8Lvw2wG0jiDqVfl2KIZ0M5NpHtst6J4B4E/7O5rSgJq0NSvV2LwKfY8ltj4ZJY1omGnAywrhZUy1gm/PVeBo+bO27LzAvv2qEKgp2WYoxWj/l8PVSexX2S4U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763087039; c=relaxed/simple; bh=thAtZa7DNmYUzRuGV8q+ntUsJ6L/crr5KAuRe3DuHOg=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=usMxBg9R2LUWWyqXaTYZXIa0nl9WSBp4TTbK7xznKvvns7JP5jVvp7mlI71ssAFEuykrQf7WNC4RIIWgxRtiopw3quE7iFLypbkghGSv8z8upHWeOtgadXGzyKXr0VknNaHH4nj8iWsA94zDzV4qXxrmh0cLT7xXJGChftcnwbA= 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=jzeM2aDD; arc=none smtp.client-ip=91.218.175.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="jzeM2aDD" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1763087034; 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=XUjyrKGTpAMxafgaVgeOC05GENR0/pzqji5IeCIQKgw=; b=jzeM2aDD3dtYstJyPJT2s7mVcdSPwYOdCaMcrnkQ5S9LD9TsCsGs1O4cNjttXGfNTho5WN zfZ1VTqaXyL3hAKeOXztLL7cz0dKeFpnHA/BQM6PEsoN8Fap242+ZxlF0aUURfPK68SEhk /cgnE0+uwJUZ/iUglY7UxqXIVmP5MyI= Date: Fri, 14 Nov 2025 02:23:50 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Jiayuan Chen" Message-ID: <42fca12aec282a64d3b5bd471124a1e94048afc4@linux.dev> TLS-Required: No Subject: Re: [PATCH v2] mm/vmscan: skip increasing kswapd_failures when reclaim was boosted To: "Shakeel Butt" , "Michal Hocko" Cc: linux-mm@kvack.org, "Andrew Morton" , "Johannes Weiner" , "David Hildenbrand" , "Qi Zheng" , "Lorenzo Stoakes" , "Axel Rasmussen" , "Yuanchu Xie" , "Wei Xu" , linux-kernel@vger.kernel.org In-Reply-To: References: <20251024022711.382238-1-jiayuan.chen@linux.dev> X-Migadu-Flow: FLOW_OUT 2025/11/14 03:28, "Shakeel Butt" wrote: >=20 >=20On Thu, Nov 13, 2025 at 11:02:41AM +0100, Michal Hocko wrote: >=20 >=20>=20 >=20> In general I think not incrementing the failure for boosted kswapd > > iteration is right. If this issue (high protection causing kswap > > failures) happen on non-boosted case, I am not sure what should be r= ight > > behavior i.e. allocators doing direct reclaim potentially below low > > protection or allowing kswapd to reclaim below low. For min, it is v= ery > > clear that direct reclaimer has to reclaim as they may have to trigg= er > > oom-kill. For low protection, I am not sure. > >=20=20 >=20> Our current documention gives us some room for interpretation. I a= m > > wondering whether we need to change the existing implemnetation thou= gh. > > If kswapd is not able to make progress then we surely have direct > > reclaim happening. So I would only change this if we had examples of > > properly/sensibly configured systems where kswapd low limit breach c= ould > > help to reuduce stalls (improve performance) while the end result fr= om > > the amount of reclaimed memory would be same/very similar. > >=20 >=20Yes, I think any change here will need much more brainstorming and > experimentation. There are definitely corner cases which the right > solution might not be in kernel. One such case I was thinking about is > unbalanced (memory) numa node where I don't think kswapd of that node > should do anything because of the disconnect between numa memory usage > and memcg limits. On such cases either numa balancing or > promotion/demotion systems under discussion would be more appropriate. > Anyways this is orthogonal. Can I ask for a link or some keywords to search the mailing list regardin= g the NUMA imbalance you mentioned?=20 I'm=20not sure if it's similar to a problem I encountered before. We have= a system with 2 nodes and swap is disabled. After running for a while, we found th= at anonymous pages occupied over 99% of one node. When kswapd on that node runs, it co= ntinuously tries to reclaim the 1% file pages. However, these file pages are mostly code p= ages and are hot, leading to frenzied refaults, which eventually causes sustained high read= I/O load on the disk.