From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 3EE1221CC5C for ; Thu, 20 Aug 2026 22:49:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787266156; cv=none; b=M570k6hrjXRTHOMOCqCKfGYSYUxMVZ+4efjzo0U4gdzGB+dWgHXSi5BunSPq7DVj+68X+RGd284jc/hDRgLSPnM0pBZ1wyz4zsUsSjgaVzAR3R6TA/giQx5Inyrg1PAqOw4hsBpiR1MFsj+kMl4j0aQm8JXK80b8I1DNB9xIO+g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787266156; c=relaxed/simple; bh=qqNG/LgzoKA6esGa86IMxeKPCAaO6buwUbBtDJA7q0s=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=eL+o/pE3zTWTOFhRCcmpOCrO+PLRdxUEuj4bi1TfOJNcG4MuWOrKPpLwPmhLuyZjDk/Omd/99mQAEfYTWyoqQ1gyZv03A7scGi+9URbsSJK3FT1gZP9cl8Y2Xf7O/qemVdmIcYgugGbcGXRqiKmDrhdhCQZPkrvX3ycfl9cfQMQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=hOb19F3A; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hOb19F3A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 449B71F000E9; Thu, 20 Aug 2026 22:49:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1787266154; bh=l1tHcHGbIPLaDej5OevvXkdwoi/qHvPdSwnHVriPzTo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=hOb19F3At/3ryOyPPVSG++D0gS6NZEK8Cqy1nDreUNxcrQj5l7g5N6OlwLxZ3hyRg FrTDB7BfjA9sjdiAlQGJOo3jJqfz+3r+X8h0O45h2yHyEOy0QF5Ks2nYbwMTvCBlug g0AneDFXAN7M04L743USCvqSJwkS8MC56NgJ5CFE= Date: Thu, 20 Aug 2026 15:49:13 -0700 From: Andrew Morton To: Daniil Tatianin Cc: linux-mm@kvack.org, Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmstat: add per-order allocation slow path statistics Message-Id: <20260820154913.3d6a821f6ba5c1f81d134a0a@linux-foundation.org> In-Reply-To: <20260820133659.712111-1-d-tatianin@yandex-team.ru> References: <20260820133659.712111-1-d-tatianin@yandex-team.ru> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 20 Aug 2026 16:36:58 +0300 Daniil Tatianin wrote: > Production incidents caused by bursts of high-order allocations all > entering direct compaction are currently hard to attribute from > /proc/vmstat: pgalloc_* has no order breakdown, and compact_stall does > not say which order stalled. Tracepoints can recover this on a single > machine, but they are impractical as an always-on fleet-wide monitoring > source, which is what is needed to correlate latency regressions with > allocation behavior after the fact. > > Add per-order event counters to /proc/vmstat, covering only the > allocation slow path, so the page allocator fast path is not touched > at all: > > - pgalloc_slowpath_orderN: entries into __alloc_pages_slowpath(), > counted once per allocation, before the restart loop > - pgalloc_fail_orderN: allocations that returned NULL to the caller > (including a successful allocation freed by memcg charge failure) > - compact_stall_orderN / compact_success_orderN: per-order split of > the existing direct compaction counters, order 0 is omitted since > direct compaction is never entered for it > > All new counters are purely additive: the existing keys are untouched > and compact_stall == sum of compact_stall_orderN. > > alloc_pages_nolock() is deliberately not counted: it is opportunistic, > never enters the slow path, and its NULL returns are expected rather > than failures. > > Counter names are generated for any MAX_PAGE_ORDER the arch Kconfig > ranges allow (10..13), a static_assert catches larger values. AI review got upset about this: https://sashiko.dev/#/patchset/20260820133659.712111-1-d-tatianin@yandex-team.ru > A per-order split of PGALLOC itself was proposed in 2017 but stalled > over fast path overhead concerns, restricting the counters to the slow > path avoids that overhead entirely while still capturing the > allocations that cause latency. Seems useful, thanks. It would be easier for others to understand the proposal if the changelog were to quote some sample /proc/vmstat output. > Signed-off-by: Daniil Tatianin Merging patches from Russian-affiliated individuals is problematic. As I understand it (not well) it's OK if the contributor's organization isn't on the US's OFAC list, and it appears that Yandex is not on that list.