From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CF37C5B543 for ; Fri, 30 May 2025 13:39:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2F9F6B0108; Fri, 30 May 2025 09:39:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE0086B0109; Fri, 30 May 2025 09:39:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAD4E6B0121; Fri, 30 May 2025 09:39:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9644D6B0108 for ; Fri, 30 May 2025 09:39:42 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 496D25BBA5 for ; Fri, 30 May 2025 13:39:41 +0000 (UTC) X-FDA: 83499681762.11.9D4BF84 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf29.hostedemail.com (Postfix) with ESMTP id 2750D120003 for ; Fri, 30 May 2025 13:39:38 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=HdHrT48C; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748612379; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yRGPAlzvwqw6A1h+zbYAm+4VpblGusAQkDYaKOqoOyw=; b=LWbOVlAHEYGTEXeypbucPjsvr+3PDG7yV0QsPeTMHKLL8PX32XtPju4kckTg/NNM5rPZYg y62GqJMnuvlKF6JwDPUAwou6+LO/cFfoGlT8CPNSQTWmxOVA1s1OyymH7vxmsjnwhmtd6b 1Uh1v4HtwJsekItYwERBpDSbgjYohSE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=HdHrT48C; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748612379; a=rsa-sha256; cv=none; b=mUIFT3C/tX87W9laXeysQ5uUEGihvkA1rBvBZl30Y8VMxRhCfytGx0m6oBnIoZFgIVvFwE Y53A+LTwhhyXVqzr3FheiZM1lhfxtSL67BQq+rfEBs1KLPnSCMx3yVrpJp+8zrKlD2vJ4b lHGnWYHaMcyn4ceKsFeJWj3pIzoxzUA= Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-3a363d15c64so1363072f8f.3 for ; Fri, 30 May 2025 06:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748612377; x=1749217177; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yRGPAlzvwqw6A1h+zbYAm+4VpblGusAQkDYaKOqoOyw=; b=HdHrT48CTnsOg90pMwDbFphN+Hp/JiyERmQJZvyBDnV/3ZqUaL3SN/z9EM2K4k+1bX h/Nay8Y81/kDtxdVdFsKzFkx1FQUoqUO9lI0d2rdF0DMrSGJrxAgNj+k8Be2EGHph/fA 1eAB1f135WGMVFbe5moQCiXWqdjTyfLjoq1aSLIOuPzoeHVzxtneq1V9OkwOLGKnSZgt IGOJqQ5uiGXKpcNqiu8eGesJdPlpattL0S9tzW0F3Ee3rV4ChogTGEhuODCk3TH8MPgi ik4r7FFd+S/ZmSDs53OOgyCXrE5JJ4S41cXh/q7izphmTf+nV0L7oKTLXL3Of6Nu8oVg PWZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748612377; x=1749217177; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yRGPAlzvwqw6A1h+zbYAm+4VpblGusAQkDYaKOqoOyw=; b=JLKkHyMUMYrOfHuui2ERhmS4SeJlZ1pUb7k6lYziCsLBSetZQ0VIQMG3X3ujqwzEoA +72yAqTlxoz+HQ32JQU/BzzwSY6Ut7a+89r4hvw/hy+cjj5wkf6Cewd+bhvj6imZzvDQ 1sbjOwDeOPMc5xS+WgumWuElpjzNVT7WW0fHfVzkGVg824Ee64kqlec45y+NdCNfZPjR c1pg19NZ/scEbxR7Dz59iX5EnvRQik7FaOj9Osj728yyqVcYvIPUU+m48V08ECXZ/e1q qqZWATlKFK0g/0tfz7vs5J88ySCpQOJJSPo4L1hLOgOM/yAh3M1fv7VxWc8RUvAMwPGs OO1g== X-Forwarded-Encrypted: i=1; AJvYcCWx3jn8c/JZC7jQfb7wlVOGL88ZfDhqyVAwsWPBLrasyeoW1Tm2KGOTnnDOHlpkKnq3sm6obyh7pw==@kvack.org X-Gm-Message-State: AOJu0YxKG00EjJmJvIaXchU+eSZW1vl/nDYY+PDwi0KCGzUSpCe9US67 TT+iPCuvU0Qm6lVOOdaZTlZ05BYFNjvIWQsawS2ZXV8YeBwiL09Dvdrt0EDYHHuemqU= X-Gm-Gg: ASbGncu632dsDVRuzDihR5R6BY/8vEINEZGrjdd+egZbZZ4jOJ/nR4yzKclY5bynmXm 8OvJkfrv7iykg60YT6XxwuJDjy2V/quUA+iKSipmkTKhYjJCW+gqzdRKlSNSmu6wr+0Nvyw2mdM AkdiXa5jy4S1AfU9FmEZQ6B4pD+VP1LQCYJ4DzO+E8uIIaKxtExtS/jdD6t7CZu/Hz5CQKyGrl/ VOns+CziAatju4N8gsP5LV7/BV8YGrNk/ZG0X07xP5Piy/CMKVoYHKeuRFuuosZX/9nl6ROEqBM wrkAraPKtZE+mkN6STOeGlZ0MdQU0Ojpd/95sTH3F5t/YW3OTiI+JJxGd4GBjxTZ X-Google-Smtp-Source: AGHT+IEo9kE2Be7pLGHE2XuA9AU0Ju3nckFIvGlZabjJ2oxMPb3m4OllHxVr60DZeTamXlijFKgeCA== X-Received: by 2002:a05:6000:24c8:b0:3a3:55e6:eaaf with SMTP id ffacd0b85a97d-3a4f7a1cda7mr2695435f8f.24.1748612377483; Fri, 30 May 2025 06:39:37 -0700 (PDT) Received: from localhost (109-81-89-112.rct.o2.cz. [109.81.89.112]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a4f009748fsm4788637f8f.80.2025.05.30.06.39.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 May 2025 06:39:37 -0700 (PDT) Date: Fri, 30 May 2025 15:39:36 +0200 From: Michal Hocko To: Andrew Morton Cc: Baolin Wang , david@redhat.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, donettom@linux.ibm.com, aboorvad@linux.ibm.com, sj@kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: fix the inaccurate memory statistics issue for users Message-ID: References: <4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.1748051851.git.baolin.wang@linux.alibaba.com> <20250529205313.a1285b431bbec2c54d80266d@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250529205313.a1285b431bbec2c54d80266d@linux-foundation.org> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2750D120003 X-Stat-Signature: q3gfeed4bngw83mosp77tzjbg688ih9r X-Rspam-User: X-HE-Tag: 1748612378-516059 X-HE-Meta: U2FsdGVkX19k67+Llu4vu0wcq7BbW8WJIETi9t2/sgdcE3kM6pzFAvxxQloQb6jHIFvDsqu+2ObJIuJwbV60uOClepYWwRFxlr04SfsHnvZBbNQCzoo40YBYruKPxbC7xhOo6nwCQZIOHcpttoKl8J39jGyM5Irkm2a9Lb53Q+UWZ+5RhpnzTuqfChGSu7Yjlam5PWKqJjGlTy8PHPuCTM7EdXtudSLklZuJRm5N8Ghw0jK4vC0MnUk84kt3vFfCiA3vw9lBB4b1dw33YEpbgw9W8iE+nQQSN3X2KYkWo70RDcffhe2jMl3vLHtJjYeP2RO6Y3ynXuw5vlPq7sGKOXlHKJAgXLEFrEVmY3dCFf/vNeMVvgeS/RAAI28TYU0gJ1l0ODQClqIrn1/CeRv/f7xAGuzFztZTd0/oR+Yy6OcKyfBuuo9jyXMMxEqyCvsu8ZJjPZ6KbVEPN4iiIE24utuIsV0kaOmjwlXMNvvktqmUMYZD0pw04mFDkZxdmIsuEiXO38ZCKvX2vy8/+Fbve3ph099Bj0Rxgc+Cor0o+3GbM4fY9A4vkaYQBuUwclGE5PXNOvouo4yoYZwQoLS+uxWwtlQPo0/dJlsGaPr1ZDXgLswZsOJnJ7JtIEul6YE7Gyl5muJEozrEt/TEmjVTsqPwbpcLNmnkrPyWrS/TZNEFkAMODMY6Mop6PG+JzrKbMJwI0GmYX1eB3pF5KUxBNl8LbAcISEr0YAtHqMDxrU+FiFLCONWqDNfKUNpvGxUJCo3DeGZKD1NsvR4A2CAtSVMKHfAkENosBCChs1WyDTiS7VxGocdmFDq7RM0gPKbipc2yqHw3gEOc+KabTFS5Sx2zJ+KTRWSEhRiS5lJaTpFL0Zm94lEuRVau/9D3XJzzwmM/ePra/FWQTkcnfhb5UQFYWayeR8ZCKOFRqQWHZuttaVCuerNONMKb9wpNAiB5q+gEhiAKZ2JLiYM6h3M YTy8UfPi W6wC7T9zbYNC+Zj+JHEt79EayS2qGb0cNCv+7LfQD959L/IkSpGj4lKwShGQTF8mI1yJwrdwQIwzGn74zkLnjOk5LX3h9TSt1fMkkxNPHdrQLAAgQ3yhQ2fqJifxDTkdSGXnM5luG+uEbRurUuTTLheo1/ZQ0rlYVgjc3X3ur4mGmcgrfphSWuMM24nKw98BgNvpc5bK8JBgYxJxwo6Hv5C7RGdYVKU1sloW23+/ZP12WmcN0kTxeZYtmHaIoZiqw6jcmUmlvUCmfj+mRTf3V+0AViVOqsbV29aMA8S59asoDL0eknWwLxVvbqLUlaq15UQh5KPOFJYKNi9lyyAdmvWFPK69YMiABXsggkC7C3Wx+PG4AzK7uuQCTupN2jYkdP0JdPKo5fvEZabk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu 29-05-25 20:53:13, Andrew Morton wrote: > On Sat, 24 May 2025 09:59:53 +0800 Baolin Wang wrote: > > > On some large machines with a high number of CPUs running a 64K pagesize > > kernel, we found that the 'RES' field is always 0 displayed by the top > > command for some processes, which will cause a lot of confusion for users. > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 875525 root 20 0 12480 0 0 R 0.3 0.0 0:00.08 top > > 1 root 20 0 172800 0 0 S 0.0 0.0 0:04.52 systemd > > > > The main reason is that the batch size of the percpu counter is quite large > > on these machines, caching a significant percpu value, since converting mm's > > rss stats into percpu_counter by commit f1a7941243c1 ("mm: convert mm's rss > > stats into percpu_counter"). Intuitively, the batch number should be optimized, > > but on some paths, performance may take precedence over statistical accuracy. > > Therefore, introducing a new interface to add the percpu statistical count > > and display it to users, which can remove the confusion. In addition, this > > change is not expected to be on a performance-critical path, so the modification > > should be acceptable. > > > > Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") > > Three years ago. > > > Tested-by Donet Tom > > Reviewed-by: Aboorva Devarajan > > Tested-by: Aboorva Devarajan > > Acked-by: Shakeel Butt > > Acked-by: SeongJae Park > > Signed-off-by: Baolin Wang > > Thanks, I added cc:stable to this. I have only noticed this new posting now. I do not think this is a stable material. I am also not convinced that the impact of the pcp lock exposure to the userspace has been properly analyzed and documented in the changelog. I am not nacking the patch (yet) but I would like to see a serious analyses that this has been properly thought through. -- Michal Hocko SUSE Labs