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 AE8D4C3DA6E for ; Fri, 5 Jan 2024 08:35:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C6046B0119; Fri, 5 Jan 2024 03:35:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 276116B011B; Fri, 5 Jan 2024 03:35:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 165186B011A; Fri, 5 Jan 2024 03:35:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 00EC38D0018 for ; Fri, 5 Jan 2024 03:35:07 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BFE744097A for ; Fri, 5 Jan 2024 08:35:07 +0000 (UTC) X-FDA: 81644597454.01.0F74470 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf20.hostedemail.com (Postfix) with ESMTP id BE4061C0007 for ; Fri, 5 Jan 2024 08:35:05 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704443706; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YVnROxHY5RVZyjEviFWd5PdWyyLwn6kJj5HUmBTqcIM=; b=HhkfzBN4ng0CtioJ6jIAolsNtAC+dQRvG4aNd6N2vLLEZbs/8Df2VjcaU1q+6ZDrg/sX67 RF3xp2GgwNLlbVJfsIIksVIutk2p+CjcXUx4xao+1/VNnNwauYxOP3ZOs8wxi9UJX7oN0e NTJXHfUiV7JmR0zQH55d+7+igwGoAFA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf20.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704443706; a=rsa-sha256; cv=none; b=NTqbVyHUPteATIKyviyj6yu6uShlDp+qaPENJzRRaKMK4WVSx2pLrja1DQifePRpSTyqVc 5d/Snd3BNMxZI8GHC7d2UoS/rY9q7BYmY4eHX5LR3UIaOUgwN0E+QweJp+CcUAJB0/dEno +N5pQ/7YWAUNSxPBMksMiwGdjtO/FLE= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CFFCBC15; Fri, 5 Jan 2024 00:35:50 -0800 (PST) Received: from [10.57.76.44] (unknown [10.57.76.44]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 248103F5A1; Fri, 5 Jan 2024 00:35:03 -0800 (PST) Message-ID: <146a88e6-a647-4b8f-8472-af3ff7ae6b93@arm.com> Date: Fri, 5 Jan 2024 08:35:01 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1] tools/mm: Add thpmaps script to dump THP usage info Content-Language: en-GB To: John Hubbard , William Kucharski Cc: Barry Song <21cnbao@gmail.com>, Andrew Morton , Zenghui Yu , Matthew Wilcox , David Hildenbrand , Kefeng Wang , Zi Yan , Alistair Popple , "linux-mm@kvack.org" References: <20240102153828.1002295-1-ryan.roberts@arm.com> <29007216-8A9B-4CA2-8A87-EB33E338CBA7@oracle.com> <84b43094-9b16-40a5-94e8-6dd4e859a01f@arm.com> <0d06b0fd-01f3-4a93-811d-f39c0b326b23@arm.com> <26dc2b09-b298-4fb7-81e1-4bfba6afaff4@nvidia.com> From: Ryan Roberts In-Reply-To: <26dc2b09-b298-4fb7-81e1-4bfba6afaff4@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BE4061C0007 X-Stat-Signature: eeyzwk8bb6yeji19xrmtg16we1ck47rh X-HE-Tag: 1704443705-808212 X-HE-Meta: U2FsdGVkX1+0BxbJZtOLcIr4KHVnI1ZiaasjZqLrX2R7DGVtI+ynpwU/ZvPRcFBaM1NqDwpvLst4uYuHtZ+ODVUyKCdm+wReIMkpacLiRiDhXgRDyfqTDo7AhVk08hLqC0tQxPow3nFJ4U/VDQpLEZkbv03Zqdnav8JHWaZQL0ZynkZDJp0EjmNlyOaCR2bQ0IhuhACkbggBpEBOsjP0kBVlrhGw2wcADd/jzBtY7iPekg3Duq1nNFXQ69LZcRktYJ72MWf+IR5IegzVqPpeJQQ3bf24K7YaU00Tq7cabPaqd+o3CY5b4+P4V4906Lxw53tGovljnAb9Ew3OO51MVQr7lftArhj09A6HhzIMUp+YTKzPzHGQ8R4gSl1X6v2Ye10uhfKRbtftOqICj11FHuAlhNvkeQJ+cKV8DC471KdFcgcQwQ4KfUlmC+nC6gzDkXeGET9kARtT6Y/lvMGZ+ov+HdRkf6zMXd++bMiiCqy9NHiq1AtsaVxB54CXsb80k0pcOa4XapAyR2v0fOnNhj99VEyLuCBdWAYZ9e6b/XIWXOspH4hWak1WpCu4y4u5MBftOqZTxTdnIWh5RKPXUrhzw+G1Ad6RRlpzZZaZ2gIGEWk3QFumoCrttCoLvPnkmZWmOVsZqmKYvkw6tCGqFs/Vkcokr1mi3GD2Lx08LFDK3Zjj13VLvQkKgIqmoENeLmY9AnAITt+gItZtgX7bX06/ZmbavVdWTUCWBHxODodHnbWArxoFETkhnONVfj5mXw1RRqTVNfmqjpaWUMJD2TW/JCsQVm7f8pxwly14ikFIMjF0f6LZW7afAOF9uR9cCZ6LOXeULWmE4c6ZsRrDJJ5QCzggBoCGsD8Tv/qW26P5jEY8V8QeIteS98BhAiabkZ3fdO+W8CkubmSR/EJgdf2DBNN3u1PihNjmPWsyvIz/aIWUmW8o9DrK3EathpyLNM7Mef6OjOD8/x2Tp9v ds6GYruJ GfqeL/F/gYj5tDOuv16IxKHPDwAiGwrQ+Awz5e7al6MlF1gRBT8LHd1gXNmoF1y6nJZleApMTin7xEUbmVmRqO/oOkIbUxn1dDdXwJYwJtw31y1mFcBYyDVdByrRvAPooChXknBC6Bj4n0/2ML6N7E/OuP+/nz6XSeB/cidKD/07kYoMOPZoPZGdB8t95XRxRiBnW 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 04/01/2024 22:48, John Hubbard wrote: > On 1/3/24 02:20, Ryan Roberts wrote: >> On 03/01/2024 10:09, William Kucharski wrote: > ... >>>> The reason is that it is also possible to invoke the tool with --cgroup instead >>>> of --pid. In this case, the tool will iterate over all the pids in the >>>> cgroup so >>>> (when --summary is not specified) having the pid associated with each vma is >>>> useful. >>>> >>>> I could change it to conditionally output the pid only when --cgroup is >>>> specified? >>> >>> You could, or perhaps emit a colon after the pid to delineate it, e.g.: >>> >>>> 000000ce: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:0000426969 >>>> /root/a.out >> >> Yeah that sounds like the least worst option. Let's go with that. > > I'm trying this out and had the exact same issue with pid. I'd suggest: > > a) pid should always be printed in decimal, because that's what ps(1) uses >    and no one expects to see it in other formats such as hex. right aligned with 0 or ' ' as the pad? I guess ' ' if you want it to look like ps? But given pid is the first column, I think it will look weird right aligned. Perhaps left aligned, followed by colon, followed by pad? Here are the 3 options: 00000206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969 206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969 206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969 My personal preference is the first option; right aligned with 0 pad. > > b) In fact, perhaps a header row would help. There could be a --no-header-row >    option for cases that want to feed this to other scripts, but the default >    would be to include a human-friendly header. How about this for a header (with example first data row): PID START END PROT OFF MJ:MN INODE FILE 00000206: 0000aaaadbb20000-0000aaaadbb21000 r-xp 00000000 fe:00 00426969 Personally I wouldn't bother with a --no-header option; just keep it always on. > > c) pid should probably be suppressed if --pid is specified, but that's >    less important than the other points. If we have the header then I think its clear what it is and I'd prefer to keep the data format consistent between --pid and --cgroup. So prefer to leave pid in always. > > In a day or two I'll get a chance to run this on something that allocates > lots of mTHPs, and give a closer look. Thanks - it would be great to get some feedback on the usefulness of the actual counters! :) I'm considering adding an --ignore-folio-boundaries option, which would modify the way the cont counters work, to only look for contiguity and alignment and ignore any folio boundaries. At the moment, if you have multiple contiguous folios, they don't count, because the memory doesn't all belong to the same folio. I think this could be useful in some (limited) circumstances. > > > thanks,