From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b3-smtp.messagingengine.com (flow-b3-smtp.messagingengine.com [202.12.124.138]) (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 A64CE22068D for ; Mon, 16 Feb 2026 17:18:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771262294; cv=none; b=XPFGw43UqzyRVvAOW+PzrQG1sN3HQh6x03wd7fniFKZkczYXuDWrWK+v/5MbbPNjHYKb9KCytZpQwzV/agMez8UM936aQjEs539upC6N5VZ0gnJDAzRXp1F2BE1kH7VO3sD6+sEx3WInP2sG1e2DzNMg0f+JP1DxS6VrJGRsYJ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771262294; c=relaxed/simple; bh=eaa3yIx9WYE3F+EAA01wcVh4sMZgWwYCQtDyTeazkP8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JSn3I+RxkQa2qbrky42rGQCIhQ3inL9PF7ASLxgS2eWv8LwXH+WpNiDQdZpL1daLyhtFv2Ar3jMk7ViNWSocSFFveW9DMjNNmERnc+bcq+HFnJn5Yh8vu0Cizqzo6toJzPRMDovMILQuEof9c4Ar28CBOhH/R+1576+yRd9TSMI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name; spf=pass smtp.mailfrom=shutemov.name; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b=Rj8DKObv; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=WFNIP4dW; arc=none smtp.client-ip=202.12.124.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shutemov.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b="Rj8DKObv"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="WFNIP4dW" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailflow.stl.internal (Postfix) with ESMTP id 5085C1300E27; Mon, 16 Feb 2026 12:18:12 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 16 Feb 2026 12:18:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1771262292; x= 1771269492; bh=x6H82OzAohnyN19364JGe1izIv70m/IuTOUlXgxlP2w=; b=R j8DKObvjsHieiP3TuSVgCMU7uOimRLxKhFx1ppk7bFFhHdiXfwUJZX3u75dK1RHx tec4G+UVqeV0DLK6kMIovGXmDzQofipZDYsmI1LKCtRvp2mgtRU8HpO1suZsT0av d6WhRoAag5lhSxK44oBfXyA8OhIqHV7gZ8TvvewL+NZPv9KO2o/1dLHGEwasvaNt uKBtq20SqVci9Ef6ihthsUxYnXPWm0nlu3L8MoqOgEG0n1Oi3HUzt765gi5wHLfH kPtP1BHiTHRma/tXF+PSpMSxMAMbaoIb0XJR2Tii/pNNy2ayZapeVVEsh1Ep9CpW W6UtjVGWe6IQwLWyZkAdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1771262292; x=1771269492; bh=x6H82OzAohnyN19364JGe1izIv70m/IuTOU lXgxlP2w=; b=WFNIP4dW4IVCOA3M01io30FMtICbVmGiJzeyDxFCrfzHwlQjmhe rRqdQZ+UrC4KpP/NMBEUwpCPM+75ObU4bjr3Gn/qQ9/gdJJv9ZgA6+b8FTZ5K2Ff +4vM9mOCDcJArlExxb1KVppDS+0bBcy7llqY+pWnNkhsEDADPvLosF3SwFaGYePX rlbA++cbHZfRo0i+0H3XmrfADWKDjo/D7L9BrAO2VBKffK0ZvtrlUyOPt92++gA/ ucg6MG/SPxudiSDICUD8bAz8VN7WB+21KXWKmY8Oabxvl/K+5NX5n/2bcJV0IQ02 3/jRwPeZUbH5WMV6kMbsm45++VveD4HkvRw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvudejgeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepmfhirhihlhcu ufhhuhhtshgvmhgruhcuoehkihhrihhllhesshhhuhhtvghmohhvrdhnrghmvgeqnecugg ftrfgrthhtvghrnhepfeetheejudeujeeikeetudelvdevkeefuddtkedvtdehtdetieeu ieetjeeugedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepkhhirhhilhhlsehshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopedv gedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepfihilhhlhiesihhnfhhrrgguvg grugdrohhrghdprhgtphhtthhopehhrghofigvnhgthhgrohdvvdesghhmrghilhdrtgho mhdprhgtphhtthhopegurghvihgusehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrkh hpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtoheplhhorhgv nhiiohdrshhtohgrkhgvshesohhrrggtlhgvrdgtohhmpdhrtghpthhtoheplhhirghmrd hhohiflhgvthhtsehorhgrtghlvgdrtghomhdprhgtphhtthhopehvsggrsghkrgesshhu shgvrdgtiidprhgtphhtthhopehrphhptheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoh epshhurhgvnhgssehgohhoghhlvgdrtghomh X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Feb 2026 12:18:09 -0500 (EST) Date: Mon, 16 Feb 2026 17:18:04 +0000 From: Kiryl Shutsemau To: Matthew Wilcox Cc: Wenchao Hao , "David Hildenbrand (Arm)" , Andrew Morton , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: Add AnonZero accounting for zero-filled anonymous pages Message-ID: References: <20260214084514.2842745-1-haowenchao22@gmail.com> 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: On Mon, Feb 16, 2026 at 05:01:51PM +0000, Matthew Wilcox wrote: > On Mon, Feb 16, 2026 at 04:54:05PM +0000, Kiryl Shutsemau wrote: > > What I would like to see in the kernel is a syscall that return the > > memory stats in binary form. Something like > > > > size_t memstat(int pidfd, struct memstat memstatbuf[], size_t n, > > unsigned long flags, unsigned long start, unsigned long end); > > > > The syscall will fill up to n memstatbufs, one per-VMA. What exactly > > filled there defined by flags. The return value is how many memstatbuf > > is populated. The caller can call it multiple times to walk address > > space it is interested in. > > > > We also can have a flag that mirrors smaps_rollup behaviour and collect > > all the data into a single memstatbuf. > > But is that what we want? Let's say a process allocates a 2MB THP, uses > 12kB of it and then forks. A lot. Now all children that haven't called > exec() see the wasted 2036kB. Would we rather have something that scans > (say) the LRU list looking for zero memory? Are describing THP shrinker? :) I don't particular care about original poster use-case. I want to see more scalable way to access memory statistic information in general. smaps is slow, because it collects information user doesn't care about. -- Kiryl Shutsemau / Kirill A. Shutemov