From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (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 DF315259CBB for ; Fri, 28 Nov 2025 13:08:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764335312; cv=none; b=SDaZ/oKyCY4Mu3FFbHVnqCOB2Z4Q6ibEcXTKc8edFIjnj62u+SEIlbfDK6U+SToAkxMYSF4w+C/+1lrx0cdT/Ha3NckrdupJjriweMuQ7O5701lLqUUu63hTOHtrMpzMwp4dqtpQKkAi9aesf3xMD4R9dSf5aSImIEhMfwk0zxo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764335312; c=relaxed/simple; bh=qjRYpKYs8MN5Gu6QX+MG55BoSrA0UnnOEX6n48hYaRA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aIskZS1Vb331W0MrSGW/Z1D/M8tr2SRDeLYTec8/YuurPzm1HcmBn4Dx9BAOVw0wMDXrTg5wZIszo6DhGHyq96IugQXNONnynE9kNsmWd33003e9gvXfc4+9bIQMMJlPb6vJwSMHirfgs8zan765CDs9aoWLANQwNBd+gZL24C8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=fTCZ3Lnc; arc=none smtp.client-ip=209.85.219.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="fTCZ3Lnc" Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-88056cab4eeso11515716d6.2 for ; Fri, 28 Nov 2025 05:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1764335308; x=1764940108; 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=6c52tLyhxFAZFK9SA+rgt/FFMyydOFAml3OBpzwOD/w=; b=fTCZ3LncQ+X62PRQwIl5qDI88m3/DC5ZxEAcof5NoZ9EB9c1AfQ8FobEsTPyv0tTtt 61khf1zetGMXQDRy94cq2mgTUcDlOFfwR9FcG+WzuT36odxpaDRH7ZdtD1R0MYrtc+tW kK+Gqs1DEtOna8fY6Btq0bEEVd7nkIzLN6zRk/qMjHWAOsz9+EhcbCVw17sRKlF+vpeB zas+am2bOM+qHxs0J+7kmYCdm07zFOhRN/EEf22QgP+5M6aIyEZSRSQZpgFLViUY3OpT pi8GwReM4pjHKXzzSd1zKmwuGgqORyyXODYkmqNOZphM2yPxm3NKe0EKQ4ngikQrBtCN D2nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764335308; x=1764940108; 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=6c52tLyhxFAZFK9SA+rgt/FFMyydOFAml3OBpzwOD/w=; b=gpfi04ep5MvjLKtzWsZUuNkGpwhOiNfRsHAvW4qIgDt/qcdmU5IcrefEGBOUs3Hp8A q4Sa8s50xdFV6ExZwaPahFZCQtWtrg1xJQz5px8GUb1t7IXVPiFnZwf+bEaNOmJwfsBu RZxnOK3VTD+XcXR949ldCCxDcQguTJxAmQ0V7Nksqus6/+OD+4ZrQXFdcVaotePtPq4M n3OaGUrYtYO3LqiOw9vLWMizsYGvQ28SCNB/Jd4XxxEFErognxsY//DAO4IP0xG5m37r k4MoO8sgpPcJ04kRDb2pUOe7D+9yhD2UWF/qHe1GMmKgCsW3R/adxE2vyTGuRsbN7giG AbiQ== X-Forwarded-Encrypted: i=1; AJvYcCVb1P0DDERx385GAOd7qmULuzmAHQLjRfwKbc5G94/JC9QqEdUdre8btd6IONHKJEIJ8XiFVPDcQJm/ARg=@vger.kernel.org X-Gm-Message-State: AOJu0YwSvFLt4S3VL3OZVBWxmNQ/B22o90KMEkn2hpGlVeB/fftMiDPq XPjxlGUEGCeRRpVkjpp7vya77dNJ4sSl/mSaTtbKt/YXvcJC6dT3IkCzET1/wRHW2+UVkKeQ5b0 p2nrj X-Gm-Gg: ASbGncuGuth0d1rBzVXh1W8CpKu17hb93RdET+RD6ymRcF9GSuHjTXIHYEAYFDSey2A me8avYDiixp9HzAvEyOdTI8h+5U0X6kXBdD3qh7lPofGVBjkeuVtLQIg0pttWVQ91hbeJHfjXqr AIAdV0F07L6Kv8Si7IQ8HjHFMnDW9oZ2G4kt1zsw/CvdidUXZRlq/SyX+8Ibmuqzgte23JVQ1IF lz/jFUV/nuy8EcI4cvwszAqxiGqCSo/KpN8n0A9o/Y+jW1SsuxEJ8YK0+Si4Y76KyZbePs8MUGA 7TqAhAHGYIm3hN0nGMS7lJcVp7aKKxRZ4zYQsKBG5MV6VyBWHFxn0spgslQ7SjHMb3C3mWrDZVf eemOg1M7hNH5A9O59DowOU/EDoAfbdRBsxMNP86lJnR4H1CUKrg90xAh9rS+B45Wcbh9AVI/asU 7EaIet0tacBw== X-Google-Smtp-Source: AGHT+IHoTOn/0L0u2/PweEXjrcM7aTYoUbYRN5p3hWVxuFtne8kJk6roodWEOJ+eRuQYsnhj8fLbww== X-Received: by 2002:a05:6214:5911:b0:87c:1f7c:76ea with SMTP id 6a1803df08f44-8863af9e876mr187203726d6.44.1764335308491; Fri, 28 Nov 2025 05:08:28 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-886524b189asm28782566d6.9.2025.11.28.05.08.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Nov 2025 05:08:27 -0800 (PST) Date: Fri, 28 Nov 2025 08:08:23 -0500 From: Johannes Weiner To: Vlastimil Babka Cc: Hongru Zhang , akpm@linux-foundation.org, david@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, ziy@nvidia.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, rppt@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, Hongru Zhang Subject: Re: [PATCH 0/3] mm: add per-migratetype counts to buddy allocator and optimize pagetypeinfo access Message-ID: <20251128130823.GA222920@cmpxchg.org> References: <97a9e695-487a-4428-87b7-cb8a505c9966@suse.cz> 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: <97a9e695-487a-4428-87b7-cb8a505c9966@suse.cz> On Fri, Nov 28, 2025 at 10:24:16AM +0100, Vlastimil Babka wrote: > On 11/28/25 04:10, Hongru Zhang wrote: > > On mobile devices, some user-space memory management components check > > memory pressure and fragmentation status periodically or via PSI, and > > take actions such as killing processes or performing memory compaction > > based on this information. > > Hm /proc/buddyinfo could be enough to determine fragmentation? Also we have > in-kernel proactive compaction these days. > > > Under high load scenarios, reading /proc/pagetypeinfo causes memory > > management components or memory allocation/free paths to be blocked > > for extended periods waiting for the zone lock, leading to the following > > issues: > > 1. Long interrupt-disabled spinlocks - occasionally exceeding 10ms on Qcom > > 8750 platforms, reducing system real-time performance > > 2. Memory management components being blocked for extended periods, > > preventing rapid acquisition of memory fragmentation information for > > critical memory management decisions and actions > > 3. Increased latency in memory allocation and free paths due to prolonged > > zone lock contention > > It could be argued that not capturing /proc/pagetypeinfo (often) would help. > I wonder if we can find also other benefits from the counters in the kernel > itself. In earlier iterations of the huge allocator patches, I played around with using these for compaction_suitable(): https://lore.kernel.org/linux-mm/20230418191313.268131-17-hannes@cmpxchg.org/ ISTR it cut down compaction numbers, because it would avoid runs where free pages are mostly in unsuitable targets (free_unmovable). But this was also in a series that used compaction_suitable() to stop kswapd, which in hindsight was a mistake; it would need re-evaluating by itself. I also found these counters useful to have in OOM/allocfail dumps to see if allocator packing or compaction could have done better.