From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5E339401498 for ; Thu, 30 Apr 2026 17:06:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777568813; cv=none; b=liymzDz4JBtqsQ6JpoWkNy5Ff6vOzgXv2zDQoYmcrbVvtn/ATtGhxNoZyQq4APUqssQSA9CiqGKP//tIGogplBsf+Vbqy4m+v0PiyKZ00/X5019SjYStDfcguKeVHUrSyj0Uf4AiLXTUc8cNZC3FXj7zCjKogLxyMmqc/pkZZjA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777568813; c=relaxed/simple; bh=dPdHfPCW7ng2kSeVyDlMheharmDFRf8Ia5tgN1rIr7g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jplbRiMlTj9/lcC0FeuCt+vvAht4uYIehXm+jRlrU1mi76W4Z+WN6hZTcAQQqcV08QzJnMCgzEusPcAwhIw3Kbqn/iT705z4feMLtsMkeZb7Px/HJ4cDUuZs8NHa+gjBdG3NbtdsMS6qdWFjb6S9ZnlRfqEUw3UTeCmv0bFtr+0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E/aLqins; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E/aLqins" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F8DAC2BCB3; Thu, 30 Apr 2026 17:06:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777568813; bh=dPdHfPCW7ng2kSeVyDlMheharmDFRf8Ia5tgN1rIr7g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=E/aLqinsRaz6E+em9mmxb/ZmPZKQBFN0qzUWyMQ1WmwBpvNArlPyD2O/izyCgrhZt eIXJpUB4ekDjPDZGqtXXWplC89vsNKrkO432KF7hiOdDOWgT0wQBFrIjP5dx7wxAhL q+74f9XyxQvN8KdY0JZ3Fac04I5MqQ/RxFaIL/wPBDm8G/Ge3ilJTrCeacwiyGTX0t KTrSXj2Mjq/KHwqqNkcbGDJTcEPN5qX1tqx64v2waZGOELXhsWRVRRMg0luurIZx/L 4CbIQD8kOgp35xgTgEmFcZyE5Bn2vIr6wPy+iQuaoCrMpta0JHLuKgmLuFkaOPOoYQ dGcLQS5WymL1w== Message-ID: <59b3dab5-3341-46dc-851a-419790eaf403@kernel.org> Date: Thu, 30 Apr 2026 19:06:48 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/5] mm: Introduce zone_appears_fragmented() Content-Language: en-US To: =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Matthew Brost , "David Hildenbrand (Arm)" Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner References: <20260423055656.1696379-1-matthew.brost@intel.com> <20260423055656.1696379-2-matthew.brost@intel.com> <76191a17-18bf-4e9b-9ab5-dc9a48abfabb@kernel.org> <291406b26b8badf2e565996515931d9ebe50208f.camel@linux.intel.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 4/30/26 09:47, Thomas Hellström wrote: > On Wed, 2026-04-29 at 19:47 -0700, Matthew Brost wrote: >> >> So again, I think starting with wiring order into shrink_control and >> this helper is a good place to start, as it fixes an immediate issue. >> >> Let me know if that seems like a reasonable direction. > > +1 for wiring order into shrink_control, and possibly also the priority > as mentioned in an earlier email. > > However for cgroups-aware shrinkers, The number of free memory in a > zone might not be an indication of fragmentation-triggered reclaim at > all, it could be the result of the cgroup hitting its memory limits. I'm not sure I understand your concern wrt cgroups, but some hopefully relevant (and hopefully not wrong) points: - fragmentation is a zone-related property, not cgroup - hitting a cgroup limit doesn't wake up kswapd nor go through the usual reclaim/compaction paths, it's a form of direct-reclaim-only So I believe it should be easy to recognize when your shrinker is called for memcg shrinking and not kswapd and thus it can't be happening due to zone fragmentation but must be due to memcg limits, and then you probably don't need to check zone_appears_fragmented() at all. > So I think if we can solve this with a combination of GFP flags, > plumbed-through order and plumbed-through priority, that would be > ideal. > > Thanks, > Thomas > >> >> Matt >> >> > >> > >> > -- >> > Cheers, >> > >> > David