From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 29DF932AAA7 for ; Mon, 16 Feb 2026 16:42:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771260156; cv=none; b=TcptqaJ97Kidwfrt5zubVKYKHR61Jvj+rNXOPe66A+I7gvMQ6laRgD/N8KuKAN76uuJQP70zXt3FHYd3tD2ehFc4+lrq+gSzz5LwfAu+x8QjJyYIe2PvhHTNuhhpEg55obB7SrSeV4449C+KRoKABbDsuJ9uIP2Nn3qItwdqtGs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771260156; c=relaxed/simple; bh=1wZh8eKqawCj74D/Bd2TJTMacbqst6xRU3ffNiVF8V4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=foHTF2Z9slYLDtGjM+0Gh9Z/VHYK52zuxWd3Kk8FKmK4aZScfm5Ejah2juV37Gfi50vRkoUM/FIJK3Uy+KrKvj53xZMv/kvdkpsUn2dIAZuFudwLg7fYmE4lxA7svPiOUV4UPE1Dh81QVSm5PzKBdI3A0Dz1aQ8EMjhIua7MO8I= 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=cAvRzS3+; arc=none smtp.client-ip=209.85.128.52 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="cAvRzS3+" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-48372efa020so23706745e9.2 for ; Mon, 16 Feb 2026 08:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771260151; x=1771864951; 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=oFhCarEUO09Uu/U8iDB3xuYqQii9sFIgHbs/DlTAlHE=; b=cAvRzS3+vMgkHZrXKcVfFccRwp0YPjr19em6Lxh7kxVLM0qDkddD2S/Hn1ejq5RgwJ 9iLTw7jdD/zkeR3uJ//aYxvWQn33HrwLj77oZtQGqz62i4QT7xh+pIK9kVQAXiE4KWfM kSPneIx9/s6nUTyA6p1d9paF4a6z/Rf5m9R/18VacgXVWcLwOWtYiLGJLRg7ZB5BOKaz jR0SiF+X9wZLvzJDSoUTM/ih2KpiBfE2oej+r3PgnSp5WrtbKfP/uiZLk0Kw7HqXDKY3 oMKEfUztKIQtU53Y4Ipd74GnLi8p2vLsz9J5jWfjCKWUtCxPeuy5eOB3a5yzih4zhIo8 Redg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771260151; x=1771864951; 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=oFhCarEUO09Uu/U8iDB3xuYqQii9sFIgHbs/DlTAlHE=; b=aSKFGWUYJimsixHenIoGEK48LQCONefuS/apKImUwYE0OYbUpygnDPW6kN74MfTvLs HVYIv27Jt86lVdbrsTL4vvYFZ8KkpyKyOhO8z+8cVSTrmHT7hAjNkRwPoG0OEumKpiO2 N7zW5Tb6cTomzkmQpSLYotLWFe2xcCULUOxNpeTnwtRXtlXYZM59/bv29GNU6bdcor8t lSodJBiv9bj8LYy9hSJ3A74PWCQet2dYVjR3sHj7hppfNYge+cc8lU3VUha3dJG2hPnV xwt8hAK2S/2WptiesRweN8npTJUWzyRfoIsM4QgugY2Fw27xBVM9uRnGO+A2s4oIuOL1 KyBg== X-Forwarded-Encrypted: i=1; AJvYcCUYw0skH5wkCkYqyCqKkqB418Xnp/w6zQqBoOS44/HkDxvTQh77phOF19duj32wERfrrxWnv+Z7JArueEY=@vger.kernel.org X-Gm-Message-State: AOJu0YzRQBIwo8bl8JrMmiz3WAFgOIB1BYNLtC9pOhXBHzMUnhAzKK4s c+4El63BLlTVlvoA/W66xRlg5M2vJYHH3Bj+lBDfjNJEz8DQTTNwvZSzXd5Cx2y3q18= X-Gm-Gg: AZuq6aL07xP4mq7H0ongTxsxh2nMGdoynHy2lRDuj9bnrnvZRsDJrq5odv6KbZySGfU bVtCmruqaUPDPzZ32tC9V7dCalH8cMTbp4oSjUUMTJMmTuhXT/YleBR2CSMnM6I2x6Qy2iph1kT gi7bQK/0cSBNSaYLKUa6aDjcRamnJAKciGPblsqo8ZmC9lRYZEYL8owXuEi2ZTY8bN//TGTBMV9 To6CpHCkiEn0Is1p8BvLGZi0WhOjB9P+mrM19OjhicUG+9Y4Yys9IXLoXGvVfUY7TomMKLquD/B 5mup3bvvRvOU2IhIDllJ6R2tVsosKAu91is5SkV9q/Jll+yIo1ps0c3FO7l84/7zdl1Ki6WD+y1 NAHgE+AapCScVRoEwaaWmFbwWnbhmgMxfdcs8ccULIfbongAS3IpwTC0Ty0PGq8nLsULNccrqTL trHMKielHk1UAqp85RONuAdgWOxsnIcqnDNS9T X-Received: by 2002:a05:600c:4e93:b0:47a:814c:ee95 with SMTP id 5b1f17b1804b1-48379bbcbd0mr141094425e9.12.1771260151407; Mon, 16 Feb 2026 08:42:31 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48370ac3564sm244993715e9.5.2026.02.16.08.42.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 08:42:31 -0800 (PST) Date: Mon, 16 Feb 2026 17:42:30 +0100 From: Michal Hocko To: Wenchao Hao Cc: Kiryl Shutsemau , "David Hildenbrand (Arm)" , Andrew Morton , 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 Mon 16-02-26 23:59:50, Wenchao Hao wrote: > On Mon, Feb 16, 2026 at 7:58 PM Kiryl Shutsemau wrote: > > > > On Mon, Feb 16, 2026 at 12:45:13PM +0100, David Hildenbrand (Arm) wrote: > > > On 2/16/26 12:34, Kiryl Shutsemau wrote: > > > > On Sat, Feb 14, 2026 at 04:45:14PM +0800, 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. > > > > > > > > I expect it to slowdown /proc/pid/smaps read substantially. I don't > > > > think this line in smaps worth it. > > > > > > > > > > That's why it's enabled through a command line parameter. > > > > One users want the stat and all users on the machine pay the price? > > That's a poor trade off. > > > > In general, smaps scales poorly. It collects a lot of stats and most of > > them are ignored by user. We need something like statx(2) where user can > > declare what he is interested in, so kernel won't waste cycles. > > > > I initially considered two approaches: > > First, exposing the needed information via smaps. This does incur some > performance cost but is the simplest to implement. The new feature can be > dynamically toggled via a command-line parameter. When disabled, the > overhead is negligible—only a minor if check, which is insignificant compared > to the full smaps cost. You are comparing content of all anon pages, aren't you? Depending on the content this can add a lot of overhead. > Second, adding a new system call or extending madvise with a new command > like MADV_GET_ZEROANON. Userspace tools can then use it to measure > memory waste from zero-filled anonymous huge pages. MADV_GET_ZEROPAGE would make more sense to me. But a more fundamental question is whether this metric is really what you want long term. Kernel can do all sorts of optimizations behind userspace back - e.g. map shared zero page - so just learning that a process has a lot of pages filled up with zeroes doesn't tell you all that much. Or does it? Also think about what do you do with those numbers. Any action performed later is inherently racy. Aren't you really looking for something like MADV_COMPACT or maybe even MADV_COMPRESS? -- Michal Hocko SUSE Labs