From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 6346B16A956 for ; Tue, 6 Jan 2026 09:49:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767692973; cv=none; b=BuFHpwX835c2k4YJKsWN4SR5DqgtE2YNQkAs7CXRlCbcDki491VFPNRePfiG1lADHJzUs4apjnjPDzI8BGC0LWZ8xQPxwxGKh69p6YD6M006LXFIOTWhHpxC/RZwSp9bYh4hK2bIAbrzPe0WIjvangHST8mdcqI6faL/83UDErQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767692973; c=relaxed/simple; bh=bUIy9l6twg2Dx5MLaRSfGNNOFikwT5WHmwk3WYjDCdU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=quuxv1z+fXUO1kgZR3R1ooF2NEW++wOknkRzDzZBT0cvL9xck/4+wNKepiyo2pYhUQA42S5vbDF4LMAunC5Ov+NM95bzKzwv8GN+bW1mW2R1SS/cbfzx1aeYwIxkyldiIwvIRjagNOumh6oqFmRkFQlHNtA6aU1g1q6W+I+73F8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=b/Nrq+lU; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="b/Nrq+lU" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-4327555464cso409493f8f.1 for ; Tue, 06 Jan 2026 01:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1767692970; x=1768297770; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hLXye61rwdrPbJ2pzSaDKjm79SWQPJ9fss4ZNFNRnnc=; b=b/Nrq+lUpski9jrhhJ+BwPUZvuu+78WtdJGXQw3cWyZvFPVl/NXk0svx5CKFHsDpB5 8Us9AoFFbUZJyV0tbWX7QF0GpcIO6OXFakxexRfqpS0jQEDEP1B4YO2t2776GXbajYgi 3T6+Pa66TIrNw6T39qUp+xzOJs8fkaf7KhS6P5n7eP/ki6mDYAKRccj2CR3wR0wmrAAl Pdz3cYQnzWhBTiNvGfmymoApwojDZQK/4gPnqoehgj/wgOZFhgJa5bL2xnuJxsgqSl5V L/J3xeK3SGP74FZH/M23MdAYNQBp7qtigg+qhOyKdf09qmhDnSLwXYvfa8cCTpSfGLqj f6AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767692970; x=1768297770; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hLXye61rwdrPbJ2pzSaDKjm79SWQPJ9fss4ZNFNRnnc=; b=ZBbrucu3McL6a59Lp0Z3ipVqx1IoExsbbpw0T9OwS4nG7yua0WBg6H8Yy2YBvemV6r WL2G63/v1Ix3sMJ30IKooq+tjg6AMjrjdUd98nB0PFQS0wHf6Ch9nSkRUwpu59cjuayb aKSqIxoGo2UfIKNTItaeMgO2z4XJIn4/MKph3cU3yxOH9PAFWOBRpt7UXSXmBsftboeM z6Trb4JldDO77LMax6f35Jq9QfAdKcg42k8TSNnK/Qn52umofP9JSrFve0b3GkFp95W8 Au01X8eNHhpgzDtT/g0YUSZ4TpLAUTNyGSt/AVz2ablbvvLZrtKb0n8uuYfx6INCy7sF HKJQ== X-Forwarded-Encrypted: i=1; AJvYcCWlthXhvjaBaZKyb2dC77O0TMThFupbliWxCQz1b9p2VmJgqSk+qsmA3Dbfw549VDho3n3ziyW5sBUgbAg=@vger.kernel.org X-Gm-Message-State: AOJu0YyCZhYQSGw9DCrGYt3Ji+ckSpbHXmWHS1Yh4e10AqbdLHCWSsD9 bhEkxtMCCxdFTFhCJfP2d5b4usw5nP/9XoUQxrGeVHHc5dXN2aIWKpZSM6bQkkXRZ8Q= X-Gm-Gg: AY/fxX41lwQ+vy6nJ4oJ2TNAjNTZcVS1zv6A7KpoFciecz2UtenyGX3Z3rquIIncnzZ VtvEoZcF9mNwuPQ7su4NGKRLaHnxyDDnLpzk2JaSLZqunuoEuao7ywtFi9dzgPuf1SNj0D2+1cS 4NoV+AL160sW64urJKRbecHOZpL49PEw2j2P8zFdqnmWbGMxcvxeN7O2Y7Vd4aQokh19QNJEjSl Hkxir+ppgsgbSQ7iPUMzKUOEri1GnhOX6Rhs2LPhZyLjTXfb2n4mkEm516XNOeWZn5ccnkR6iBI JJ9JWnbuaz3d1oSPV/bTtmAejlbsDv1RM7uA5h+yr+/EYUWvQboTOw8nH74VBkzZwGdx50h4Jlg g+woOz52lEVo89tEUPxIeRidvXB2x5ir4KmIQO48k9zEwFpWo9gTm48GfZkBJApuGFRHNaAKIcF IFRZiBSr3RF0/PnBlDVdeaEwhK X-Google-Smtp-Source: AGHT+IGDB7ogjDO7PVr0sLCSJzXOWSS+WkgmJxvNiw4IgeCz5dk50kn1D15alayXabyMi1PwRKaRhA== X-Received: by 2002:a5d:5f51:0:b0:429:ba48:4d8 with SMTP id ffacd0b85a97d-432bca31225mr3446585f8f.25.1767692969633; Tue, 06 Jan 2026 01:49:29 -0800 (PST) Received: from localhost (109-81-90-116.rct.o2.cz. [109.81.90.116]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee893sm3339336f8f.37.2026.01.06.01.49.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jan 2026 01:49:29 -0800 (PST) Date: Tue, 6 Jan 2026 10:49:28 +0100 From: Michal Hocko To: Jiayuan Chen Cc: Shakeel Butt , linux-mm@kvack.org, Jiayuan Chen , Andrew Morton , Johannes Weiner , David Hildenbrand , Qi Zheng , Lorenzo Stoakes , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] mm/vmscan: mitigate spurious kswapd_failures reset from direct reclaim Message-ID: References: <20251222122022.254268-1-jiayuan.chen@linux.dev> <4owaeb7bmkfgfzqd4ztdsi4tefc36cnmpju4yrknsgjm4y32ez@qsgn6lnv3cxb> <2e574085ed3d7775c3b83bb80d302ce45415ac42@linux.dev> 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: On Tue 06-01-26 05:25:42, Jiayuan Chen wrote: > That said, I believe this patch is still a valid fix on its own - resetting kswapd_failures > when the node is not actually balanced doesn't seem like correct behavior regardless of the > broader context. Originally I was more inclined to opt out memcg reclaim from reseting kswapd retry counter but the more I am thiking about that the more your patch makes sense to me. The reason being that it handles both memcg and global direct reclaims in the same way which makes the logic easier to follow. Afterall the primary purpose is to resurrect kswapd after we can see there is a better chance to reclaim something for kswapd. Until that moment direct reclaim is the only reclaim mechanism. Relying on pgdat_balanced might lead to re-enabling kswapd way much later while memory reclaim would be still mostly direct reclaim bound - thus increase allocation latencies. If we wanted to do better we would need to evaluate recent refaults/thrashing behavior but even then I am not sure we can make a good cut off. So in the end pgdat_balanced approach seems worth trying and see whether this could cause any corner cases. -- Michal Hocko SUSE Labs