From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) (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 CD60919F13F for ; Wed, 18 Feb 2026 07:52:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771401126; cv=none; b=ojtgHeK62CwsMkLpJnN40HWFA8nmeJkM5wV1RI4P3V/1aYuVbWx1nPbpEuUN8lT5nopFmOBD5J6YKdlSxsRtA+gPqpWL2Z3DFDVagdlqKdmNEZH3wYXeggI2YmX2/sGm5tilUJtQr42P9ZEvuLbSXqY+5Ap533wQDBUgCebr/CI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771401126; c=relaxed/simple; bh=gTuk3Y63nKFJiwNtPbG8ttZyRJiqZtrJdjxOBrHyoy4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n2irXGlT+DUPvH9KxdvRCYWKDk47gEtfkSh/tfgWwZ7TkPlmB8VFKDviqQB1nrh9QUN1S4QRStPX+mw3WcMyif/2uyfc2zSSfy8Xuoj/vg92K7ry7UZm2900L+wf9jyA0gsLCKIxfNq1Dvix/AVjx7xLWM6LeUs/LbFGBiJUd7Q= 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=UIeRSm8a; arc=none smtp.client-ip=209.85.221.68 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="UIeRSm8a" Received: by mail-wr1-f68.google.com with SMTP id ffacd0b85a97d-436e87589e8so5974913f8f.3 for ; Tue, 17 Feb 2026 23:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771401123; x=1772005923; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ntZdvUFQplwCFL7s1fQ45P/X2oyjzcHIko4bs1V/f+I=; b=UIeRSm8apnwGUh7+0MeXgvBhL+udzeT2sOW+OjFvLVDbLvH8fUf6Ogql8F0M0p7Epg cmjeKxZB43x5i+/3x1hBhJmnS2sNGyea1bXeqitorZup8uRiQkDowh5XiZ4hp9v4GPh3 BlPL5x1JPZeianIBpa5Yq8jLG6ZMz+8zJr5QQ2/YmTkBlhwLMlmH8KJ1VaWXTIXO2GcP pCDjgNSsuzW9yZINmJF+1+4JUxKHRSNBABRShV53IFiEMcACdS7F+wwfKBVh/WCk1ZAB WyV3Zkv9zPz+i4ehSsCn++CphRRMLXwYzu/XszjT47UQEpd3bm9+MkPY/MwXpi4TYx4Q mRZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771401123; x=1772005923; h=in-reply-to:content-transfer-encoding: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=ntZdvUFQplwCFL7s1fQ45P/X2oyjzcHIko4bs1V/f+I=; b=E/Mm6OK0KcFJ+wQ9xcTJvJ+0ftBo5gj95a57oxsR91I750//R1QCgHqlXOEn8tCNvK C2Z/pyj5DzBSSpcXgvzSvTh9xGZX2SiWEZmmZJM2i18sjNe/5S96FV9Z/ej4IgX1u4cu EtTOu60oBa7VR74KURQtSHGNTMKgVvOX4wcsA/kmO5jUTotLXpZoQhK24tMlk0v9Mkgb aDazSRVJiEIaBXsOdQNIHh7GfWi+tZRnG6ZtWmAsIBXB7MRdFeLQjDzACGqpd+epJWjf FP6LJxZ1MM5D4hKhRGlvFkshcEQVxnVX4SkzTajRYWjQJ4jETPeUPAcg/9nkB1fRNXC4 WGow== X-Forwarded-Encrypted: i=1; AJvYcCVTQEC97taShWECbWQIg/g5wh3EJZPgh9zcmrO2ncaZxOQpeXQJCsX7b2/hTiSsub7kNW22YGzPT9ZRanw=@vger.kernel.org X-Gm-Message-State: AOJu0YzkVS0Oo7/e71oVRQ+xHNvQwOivyMbrI2rZqNoQC/ldAjUse+ZQ n4BMPpOK6PJlK678mB3ZZBXsfpqT2cdcgUj/l40KyIw86CYKDZMgY0ZUiP+0coXkrlU= X-Gm-Gg: AZuq6aJ5NgAdSdsu+y43u9ViEdiQv3i24IFyNSCTJZQM4SgZ/nkclGam8jS9CGQwV2q ZKpLJVFS2lpPPwNRW73xdiOywat9Tvg4SUbK8i9P5Fx2MPcu9bzrDZ8txaGpIjDs6UrfN4xrS1f jy2nSbI7IKXQTpxZOBqpE0ftf+UdEYfYfuhSiQ3bMUem3p3sbp5wc1Dh1jIsmqElikf9tcpYdpg Z00dG1xdGXMc9IiRZuXpa7PUrXrscrqLySESuzkEyZdCj9XTN9j25iqNHwOTE8YEnIv3LKg5Quf vVdsoQAKoiUbecH5tgExbssWyxAuzS03vtsDg/MoY8MxXUfW+UEoXbgxqn4frQHLEZVHCem5DW0 eMv6y1q541DIy4BeVDba0qro2GwB23HngbB921uUp+AKcza7sTvMoj8LC/9zDlodw1Yp6I5I8Vi G8UzSjhIkwk/ieLtR28pN5Itijy1qhs46qlUtN X-Received: by 2002:a05:600c:4f44:b0:480:4b59:932e with SMTP id 5b1f17b1804b1-48373a0a0c2mr261220115e9.11.1771401123031; Tue, 17 Feb 2026 23:52:03 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4839712324asm13737895e9.3.2026.02.17.23.52.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 23:52:02 -0800 (PST) Date: Wed, 18 Feb 2026 08:52:01 +0100 From: Michal Hocko To: Wenchao Hao Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 17-02-26 23:22:20, Wenchao Hao wrote: > On Sat, Feb 14, 2026 at 4:45 PM Wenchao Hao wrote: > > > > Add kernel command line option "count_zero_page" to track anonymous pages > > have been allocated and mapped to userspace but zero-filled. > > > > This feature is mainly used to debug large folio mechanism, which > > pre-allocates and map more pages than actually needed, leading to memory > > waste from unaccessed pages. > > > > Export the result in /proc/pid/smaps as "AnonZero" field. > > > > Link: https://lore.kernel.org/linux-mm/20260210043456.2137482-1-haowenchao22@gmail.com/ > > Sorry for the late reply. We are now on Chinese New Year holiday, so... > > The original goal of this patch is to measure memory waste from anonymous > THPs - pages pre-allocated on fault but never accessed. I believe you wanted to say "but never modified". Unless you map THP through ptes you have simply do not have that information. Reading zeroes might be just what your workload needs (e.g. large sparce data structures). > On memory-sensitive devices like mobile phones, this helps us make better > decisions about when and how to enable THP. I think this is useful for > guiding THP policies, even as a debugging feature. > > Let me summarize the discussion so far: > - Matthew Wilcox questioned the value and raised concerns fork but haven't > exec path > - Michal Hocko criticized the inefficiency of scanning zero-filled pages. Let me clarify. I am not objecting the inefficiency. _If_ you need to recognize zero content then there are no ways around. I have merely mentioned that the overhead is not negligible for /proc//smaps as you suggested. > - Kiryl Shutsemau prefers a system-call-based interface. > - David Hildenbrand acknowledged the value and suggested implementation > improvements. > Please correct me if I missed or misrepresented anything. > > I suggest we first agree whether this functionality is useful for upstream, > before discussing implementation details. Completely agreed! > Reasons why this should go upstream from me: > > - Anonymous THP can introduce real memory waste, but we currently have no > good way to measure it. > - With accurate metrics, we can make better THP policy: disable for > low-utilization cases, or early-unmap to relieve memory pressure and so > on. This is especially valuable for mobile/embedded devices. While I agree with your first point I am not so sure about the second. You can easily run the same workload with and without THP enabled and compare the rss to learn about a typical internal fragmentation (there are several layers of precision you can influence - only for process, madvise...). This is a very crude estimate but it gives you some picture. Is it convenient. Not at all but likely sufficient if you are debugging a reproducible workload. So I would start by explaining why this crude approach is not really feasible. You are talking about early-unmap. How exactly do you envision this to be done? I mean finding zero pages is one thing but how do you make any educated guess that that particular sparsely used page needs to be broken down and partially unmapped. What kind of interface do you want to use for that? MADV_FREE for all zero subranges? -- Michal Hocko SUSE Labs