From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (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 A82FE4156DF for ; Fri, 21 Aug 2026 07:50:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787298638; cv=none; b=mOpo9TAf8mKitBTEBKzHoL35cNIm6XChWv+eaDdXndgNyTbS1DkaiclBQkxc5If36Cf43Ir64h1IS3/f4BBbwkPivVBa8IXQHI+LsuDr5CnKCY8KjWDXvgNSrzamQ9szdRZVfpF0sOh6n76NCzTrUEAD9PniSzKQ7zV6/3YYve8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787298638; c=relaxed/simple; bh=7e+LVj16zhItlrybzmbtgc6TgKXOZpffHfsQ+CrNSUA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LLOQ87Rxnv7a1lDPffOR5KVPP0+n1skNf7Jn4C1ew+o8oJ4Slt70C8ap7oqTWv16S1vzY/SGLz92jltkoFUNo9OHaE+P0N94Y3DXmdjlW3HAmst2zkk+bSZk6f/ZlE8HQptgw3uNZMIMgsPUiB34RLilQFja0MHtiiiTWPK8tGM= 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=EQJTSrQx; arc=none smtp.client-ip=209.85.208.42 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="EQJTSrQx" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-6a051b737d8so1037285a12.1 for ; Fri, 21 Aug 2026 00:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787298635; x=1787903435; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9RWA+HUT3W6AsRkOLp09q1KyYn/E9QflCE9F4xeuhlo=; b=EQJTSrQxk/hjorehcXNSo7+CyunFFHnJFxmG7vAE6Va5NPW7RHbkQOlUpg7ehQJhd6 12ygpgfi/aP9NTQZImCuV2g/de1wCzitHwIqJie8yaga8QNvZHP6dRL8IIwwEdXIdqdL ycSWo0umkaq6DrarOth8/gT9fyNfC0916CI3cSDDUzRsYEH5rc1LcTE9BDzIYfY9dWQW 1bM2RmQV4pL7RaFct7yC79eXs+Zh4Fbt8j1OMXDkf1n0IlY9phOJAKK53YC3bb2mGJ1c S2tFCBSW9C37scSjSfRVgQKvY4Xx1xDF79i/Ig/oDOY4/ObaaMOaia/EvmSo8p4QezX+ yadw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787298635; x=1787903435; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=9RWA+HUT3W6AsRkOLp09q1KyYn/E9QflCE9F4xeuhlo=; b=oDTM5fTStbZzek3/iyAJA285ge2JqSPhnDUV6hZFqyXg0IKE/jTv9LM2ZwOPMM8tSU QUj7ZTq29RE+cwMW/YaLhf8NUPIJqxcw0JfBBEWLYcJ3XCBpZyXeNizVCZox4kr9ZyCu KmfNOr3GLtMofBGxAEZtd0ax/3+oYLVURXB/eUaKHFaWC6NeBMkSxLwRpUiHAzhVulEb 5neHCUDyJwUnEjmrL6iedVfe9RMllLL8MixSKuV/ZM1J+u8mqs6SfiUCNEeUwMfWXScA TZoxMr2X3mUBb8cIPsLozhsp+1E9b/hwQBCKqcFMnKYMi2bxvcUER71UrPUQ718lUawL HI8g== X-Forwarded-Encrypted: i=1; AHgh+Rp0Uvjt0DmAn7219R4ofzF9VZqFtThEEb4ItRTj/6Oll8h/bcy3mmTeceDViq+YVqd2XSnrTnZ2nhU1t9U=@vger.kernel.org X-Gm-Message-State: AFuF++na0/xRfS5EMLUbPFRjXfxYPL6vMypkVMEghAErK5PDOe9Az/7w K3VKtvPuUZDG3NSWnLvLkvIKz0RV6s2jfwhr8raRs6TwJJkJSHvACVkw+ggtx75tnrA= X-Gm-Gg: AR+sD13dx5rauxm2/8aQRP/VX0wUQRWgV51Py5FUNKwzIDAtwEVhqAGpKa52opVFoAb DS0ggsgfO5J4UOdpg1cvVpn/EforOj42NV5XhBWCRjQgb5PP+EwzI3iHK4YrHOspkY9KliKoHxN ar2PqLK7jFYe0/s33NkjosuAVJk2c+JimiFWgDUq4nDXaFTNJ8/E45odrW6nk+Id8T4TlTRl6jF +mnyj94sCu7pekSVv31c2F8NV9xS25dzJHgt8JwenrSyU4Bb53eOSPVX+pFAXzs9ndg8zHJ+gj0 AzAzauS5g4ZFVGDo1kxpR+/dRcR7bnIK5i26x49cjZLhv3bmqaqfLs0l+3ZVEZWUKokOpnQOuKs Icqt60l7outThSLTn51o7fd1osvgDmHVJHU3m3EebSGvtgtgLMx1pQ9tO/ilaswhPVtLD5fKZz3 2RvJ9wMQSgx57zYsD8jOkzS8HdRtyjoxNKFO1bGsHDOV4nA3ecWqE/orfMoHTeLypB0i/M0++o8 A== X-Received: by 2002:a05:6402:27d0:b0:6a0:9c84:ce0e with SMTP id 4fb4d7f45d1cf-6a42f20af9bmr4666831a12.14.1787298634871; Fri, 21 Aug 2026 00:50:34 -0700 (PDT) Received: from localhost (109-81-81-112.rct.o2.cz. [109.81.81.112]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a3ff156811sm5060563a12.19.2026.08.21.00.50.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 00:50:34 -0700 (PDT) Date: Fri, 21 Aug 2026 09:50:32 +0200 From: Michal Hocko To: Andrew Morton Cc: Daniil Tatianin , linux-mm@kvack.org, Vlastimil Babka , Suren Baghdasaryan , 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: References: <20260820133659.712111-1-d-tatianin@yandex-team.ru> <20260820154913.3d6a821f6ba5c1f81d134a0a@linux-foundation.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: <20260820154913.3d6a821f6ba5c1f81d134a0a@linux-foundation.org> On Thu 20-08-26 15:49:13, Andrew Morton wrote: > 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. I would rather not put that into ever growing vmstat and bloat it even more. Most users simply do not care about that level of details. What do we expect next, per migrate target/order stats because somebody might be interested to debug fragmentation better? Would it be sufficient to have a dedicated debugfs interface? The argument about tracepoints scalability is also rather weak. There are examples of successfull bpf, tracing deployments at large scales so this certainly is not a new problem to tackle. -- Michal Hocko SUSE Labs