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 20C9531E828 for ; Thu, 2 Apr 2026 07:18:14 +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=1775114295; cv=none; b=RFnt0h+uXy4xiTN4u9SYNnsYhQGTsEHC5e2bWq9B+lKZ3w2cd+QOPSpO800Eeumd5XoKhotvw6jcBZ+NJeLKaLWHNBmF9jMMjyFoXpxVQKlovMGob3zMS6LDLvL/lCtget0zDOaQaopqfOdo2mKP1dhn76fa0uEqlQtM3bJaOc8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775114295; c=relaxed/simple; bh=fy7UMXiTtfEMvHGT15AdWnHodjKCat8W/RCBGjMJU0o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=E5B0Wc3aPUJP1dyl+MU3ndF0Fgj8EduzjHKcLLsvbggBFpfCMxfIFjypLTFUDAlEjCEto1H2wybdKJp2kGpepi/fZF99w7Dqqqx8qJMtQVI2/9+qIxoqnWGWSYIhwaw51PlrfuYEn2wtEA33O5d6L2+Vtb1M9pNi18me7xm2vek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s5ZOSZxh; 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="s5ZOSZxh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F6A1C19423; Thu, 2 Apr 2026 07:18:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775114294; bh=fy7UMXiTtfEMvHGT15AdWnHodjKCat8W/RCBGjMJU0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s5ZOSZxhqKvdMeH3P6ArEwlNL7hRDgNzvHh7o5NVZ7IRUdm/vwo20hy3ZY1xelnl/ VUBvmgMcHAk/0d8zlgdVYX0fIDpXf4OQK1f/wzSxp8mIp+KiiO2a5shfPAr6EaaS99 lYnO3+0gv4cVCQyElxFqB1unoRFrj9GLMtjCIqexnXDR9D83xFWqHG4InuPE4EBMls SBNcFBavPPLfpcZIZmPdXgheiXjwDofF6JZk01Xj4F+rfF3lDU6Kr6taSN7cO/CYZs lnkoL0I1jUuxycEsBIvO8h6pUzx+xf/Yg5gIK057LK+LCv4rFWt3vqQiPKZZUnHXbS xyNwuCoh92pwQ== From: Barry Song To: zhanghongru06@gmail.com Cc: Liam.Howlett@oracle.com, akpm@linux-foundation.org, axelrasmussen@google.com, david@kernel.org, hannes@cmpxchg.org, jackmanb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, mhocko@suse.com, rppt@kernel.org, surenb@google.com, vbabka@suse.cz, weixugc@google.com, yuanchu@google.com, zhanghongru@xiaomi.com, ziy@nvidia.com Subject: Re: [PATCH 0/3] mm: add per-migratetype counts to buddy allocator and optimize pagetypeinfo access Date: Thu, 2 Apr 2026 15:18:08 +0800 Message-Id: <20260402071808.41828-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: References: 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=UTF-8 Content-Transfer-Encoding: 8bit On Fri, Nov 28, 2025 at 11:11 AM 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. > > 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 Do you have an idea how long each seq_printf call takes? Assuming seq_printf is costly, printing while holding zone->lock may be suboptimal. A further optimization might be: diff --git a/mm/vmstat.c b/mm/vmstat.c index 2370c6fb1fcd..f501ca2840a6 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1570,6 +1570,7 @@ static int frag_show(struct seq_file *m, void *arg) return 0; } +#if 0 static void pagetypeinfo_showfree_print(struct seq_file *m, pg_data_t *pgdat, struct zone *zone) { @@ -1611,6 +1612,63 @@ static void pagetypeinfo_showfree_print(struct seq_file *m, seq_putc(m, '\n'); } } +#endif + +static void pagetypeinfo_showfree_print(struct seq_file *m, + pg_data_t *pgdat, + struct zone *zone) +{ + unsigned long freecounts[MIGRATE_TYPES][NR_PAGE_ORDERS] = { 0 }; + bool overflow[MIGRATE_TYPES][NR_PAGE_ORDERS] = { 0 }; + int order, mtype; + + for (mtype = 0; mtype < MIGRATE_TYPES; mtype++) { + for (order = 0; order < NR_PAGE_ORDERS; ++order) { + struct free_area *area; + struct list_head *curr; + unsigned long freecount = 0; + + area = &zone->free_area[order]; + + list_for_each(curr, &area->free_list[mtype]) { + /* + * Cap the free_list iteration because it might + * be really large and we are under a spinlock + * so a long time spent here could trigger a + * hard lockup detector. Anyway this is a + * debugging tool so knowing there is a handful + * of pages of this order should be more than + * sufficient. + */ + if (++freecount >= 100000) { + overflow[mtype][order] = true; + break; + } + } + freecounts[mtype][order] = freecount; + spin_unlock_irq(&zone->lock); + cond_resched(); + spin_lock_irq(&zone->lock); + } + } + + /* printing completely outside the lock */ + spin_unlock_irq(&zone->lock); + for (mtype = 0; mtype < MIGRATE_TYPES; mtype++) { + seq_printf(m, "Node %4d, zone %8s, type %12s ", + pgdat->node_id, + zone->name, + migratetype_names[mtype]); + + for (order = 0; order < NR_PAGE_ORDERS; ++order) { + seq_printf(m, "%s%6lu ", + overflow[mtype][order] ? ">" : "", + freecounts[mtype][order]); + } + seq_putc(m, '\n'); + } + spin_lock_irq(&zone->lock); +} /* Print out the free pages at each order for each migratetype */ static void pagetypeinfo_showfree(struct seq_file *m, void *arg) Thanks Barry