From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 CB5C52BE031 for ; Mon, 16 Feb 2026 17:10:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771261835; cv=none; b=RbaqpKouxsimHC7l18RzjftCtu3FzQWZ8jptWUxYMHt9Ae6xwCbbAWwBTrpMIB+DuCE1OXLzZRj/RQPy8phubHAPzcQmt0dz0BVH+Da/Au/ETACyieoowTHrE/tS4/BLCROktGfSZu+BDyrnNBVTfKNkNoBOJ+l9hV6/an7mDig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771261835; c=relaxed/simple; bh=hRrVNjir/ZX/K1hES1GDc1Tv6FZhbhnigj5CAP7nshk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZcI62gd1sHG7M0x/IDYJVtanU/ZYFb4pkX5P4Vxnx2cC5iHvq6eo0V7pp5Q/0ATVjEIilFC7BER996vSRxYdmeD8rL+wnn7tgNg25oGycFm3wVUs0oTCzpS+sYsD3/wqtOcW9mV8ZUXSPJrLG8ZL+TTXTDS93QGs3ZeYYH+CgX4= 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=Szyq4GuI; arc=none smtp.client-ip=209.85.221.44 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="Szyq4GuI" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-436356740e6so4057066f8f.2 for ; Mon, 16 Feb 2026 09:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1771261832; x=1771866632; 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=Ts+ToIC24od9T8pLPmtCu2HwoJ3ic92IWD8nk/aCwSQ=; b=Szyq4GuI1nlIvcFEYvMQccckGo1mjui+nE3bOZhUc1XIli3w9hPBnMxhke4aTVzzBX sW6ow+AxpUywlSlpyyuOA23RqiCt4pZxVswHp2NEC8s4l7X0Xie64w20w12RcSol//bS Dw+JKqX6e4DhTyqTxH3XoDUufQ3hqZXrx4N1J4t87lVntsvYNaL4B2C6TGXee8ucT02j pFPUKk/A9cWaEIJ8XYfP0MiQ64D8REkAEAQNt/BJg/O1V5EoVcmWR6xjE/6M6QikARkE KY78p3tsqrWYwIZO2lTzrDgSW6keWJMPN/LfxWQ7o6RUQpdPMuSaYr2Iy8uhIjAjDX9k bSPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771261832; x=1771866632; 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=Ts+ToIC24od9T8pLPmtCu2HwoJ3ic92IWD8nk/aCwSQ=; b=USXi2vi1ulRWn7dJmo2J7xTGFLlYKAexmDejzQfnkuZbdKDZ1VLVEJcMROXq+js1SE WOlvekIqs/VVJNFXlfCpvORV61FJtlNc7dzUWxbNYr9PfwXQrwzIusRZXEagSO4dTG9M mYd9UpidDDI4dHx62pXxvNCTmH1D8PXJrxXGqrZe1MGVsFTEtdJTfZvpO4FJJ9AW7kU7 DIe8WKFF7vyjs9NGAVM3sViGgVx50W2uBILGYNMy+aw5smn7Td0rst6kHMrXogckOdPl WxX5d6fjXLyWF8CPqhXLyP8M+gQ3PBawReSi1G3Sd/vuRnvKcYCGZLjvXNxrtB4n1VL4 jk0Q== X-Forwarded-Encrypted: i=1; AJvYcCWmZWtNj/4rD4Rpxk9zyzh/5NigjUnZYGr7PAAeQh75ZGIg+qP7P6u3ogmYmkJRR4GEmP3kjk2L5/nPeTg=@vger.kernel.org X-Gm-Message-State: AOJu0YxjoHs8jdyzKIsIo5LA0yIAJ7nmJdf8Vy7PHSp5RLLRaDLphOSO gRpZI9MRETZT70d9noZ5+JoAOF8ykKvaeJy+dRIo53NTlONmwZkmGXTdV72rONaGZ+g= X-Gm-Gg: AZuq6aLIgKmkPLNzNhIsiiWqZXubZNT0DTcAf1bkVjPI+ySx6xdFpP+5LLwcCshGr85 Sk6R41SZgTaKXCI+IP2sdG/gDKHaVit5optdGuOHHbwvYvvXp1feUDWlZmBVxV2H03P+sLgynQN sJxFzgo7CaisEdbJJp1m80Erj8IAUW/dxgVw1nEfqnkrN0mpZOHI51xNWCM5I/DRfC/UvVAzlyf YYfJIXocuIFsTW0nKyjwn6ghErFUMtB45oql8DLtAuwyzbbwJX6EU1TgbomZjlJvcfLjAcaX37W oOPoCXRBQE3E0v3ccJsF0iCXLu4+XH3+ETQccUyRqnIq02ihsYEWxGKdcHOSZbqcD2hH85em5KC lH3oDisDFqyIzcwLxoXnjBb4YAVtJchQgTMUsOKzyVnlNBTcHPgA/BtnQn2ZC9duUxLNsXXpBit QXNr7bFaXO/WplFg9qFETalJUI8zdokNlZdN+dI8Bpu3AMU5U= X-Received: by 2002:a05:6000:288e:b0:435:ab34:93bb with SMTP id ffacd0b85a97d-4379db31b8emr15860523f8f.12.1771261832037; Mon, 16 Feb 2026 09:10:32 -0800 (PST) Received: from localhost (109-81-87-131.rct.o2.cz. [109.81.87.131]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796abc21dsm29818963f8f.20.2026.02.16.09.10.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 09:10:31 -0800 (PST) Date: Mon, 16 Feb 2026 18:10:30 +0100 From: Michal Hocko To: "David Hildenbrand (Arm)" Cc: Wenchao Hao , Kiryl Shutsemau , 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 17:56:12, David Hildenbrand wrote: > On 2/16/26 17:42, Michal Hocko wrote: > > On Mon 16-02-26 23:59:50, Wenchao Hao wrote: > > > On Mon, Feb 16, 2026 at 7:58 PM Kiryl Shutsemau wrote: > > > > > > > > > > > > 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? > > If a sysadmin wants to see where THP hurt (zero-filled pages), surely > MADV_GET_ZEROPAGE is the wrong (ugly) interface. The question is whether sysadmin should really ask questions like that. Without a deeper understanding of the workload the answer could be misleading at best, no matter what interface is available. If you know and understand the workload you already know that THP is not a good fit and you do not need to ask about that. If you want to understand whether your particular workload has a big internal fragmentation due to THPs then MADV_GET_ZEROPAGE sounds like a reasonable fit to me. >From a sysadmin POV you care about the overall memory consuption, right? And for that I believe you need some sort of high level compression or similar interface. -- Michal Hocko SUSE Labs