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 5B5E5C369B2 for ; Thu, 17 Apr 2025 06:07:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4DE82800CE; Thu, 17 Apr 2025 02:06:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD79C28011D; Thu, 17 Apr 2025 02:06:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F1C92800CE; Thu, 17 Apr 2025 02:06:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 52F772800C0 for ; Thu, 17 Apr 2025 02:06:59 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9830E80F05 for ; Thu, 17 Apr 2025 06:06:59 +0000 (UTC) X-FDA: 83342502558.19.C698294 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf01.hostedemail.com (Postfix) with ESMTP id 9378840003 for ; Thu, 17 Apr 2025 06:06:57 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=osandov-com.20230601.gappssmtp.com header.s=20230601 header.b=yB7ZhTTD; spf=none (imf01.hostedemail.com: domain of osandov@osandov.com has no SPF policy when checking 209.85.214.174) smtp.mailfrom=osandov@osandov.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744870017; 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:dkim-signature; bh=zGJ5OgB+eNLxh6yjEt0KC7v1R+HDpylF2/CRuaG8Yrs=; b=pkC8zT5SNCri1GAMeR4r5brLJdu7Gp1tLsvPtjfUdXBD+/MIUSks/FQzaiCU3zsN0E8GdQ JXZ5mkEppusbkAQMmmF5DQE4v1BXm5A33Ny6E5tln0EYEwj2q1azF/ZROuAZn1N86iDAzw P4+Gr0IZ6Wpj2EE+1eJXvBjxTG20w5M= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=osandov-com.20230601.gappssmtp.com header.s=20230601 header.b=yB7ZhTTD; spf=none (imf01.hostedemail.com: domain of osandov@osandov.com has no SPF policy when checking 209.85.214.174) smtp.mailfrom=osandov@osandov.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744870017; a=rsa-sha256; cv=none; b=x/2euXNdzTF15WcNqe8kOA8bX5znGMaJXXIzrKkG62cb24mP8FNftyLLNOLnIYsi9csQwF fMZTrNyI3fg5k+sy0xUrRnUF8bsT32jISSiGpVX0Xo5I6HluGPwrD2lNVU4FQtyUtLo1Ka SpmjG5PjNULFXu0qJ+UXbyBC8htbAV0= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-223f7b10cbbso702975ad.3 for ; Wed, 16 Apr 2025 23:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20230601.gappssmtp.com; s=20230601; t=1744870016; x=1745474816; darn=kvack.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=zGJ5OgB+eNLxh6yjEt0KC7v1R+HDpylF2/CRuaG8Yrs=; b=yB7ZhTTDw9UwthES1maz3LhHy+eASELbnSxU+wQ/5WkMOvpvRttY6gaPDNUZmKAIEM SkbVyia9mNunGCOfo+LJ+ksffrmx/jxvJG9f1MNhtM6qLLe5uXVOLxsy3l39UiDFLjwe LTz/Hw64BSCDUzCERlyV0mOx2RPmfAIL59/J9XVZUYM914nfQ6p8TpwLHduuFqLtEuuC DFSKw5kuUd2sG8pJkAK7VLqlZ5G1SVijV5+D3YSQc6vH4awTbWYddNgcPe/uevgo1CQ8 /h80jYcuMILQop92l8uovTCmOMz5W3I2FGv9iS4Q6iooSMEodAii9Wbp1x1eti9+IiAg 20Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744870016; x=1745474816; h=in-reply-to:content-transfer-encoding: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=zGJ5OgB+eNLxh6yjEt0KC7v1R+HDpylF2/CRuaG8Yrs=; b=QjWkgSmS7iSGUdNZ7z+e4ikRTwb3aUzmKkcLs2o8ybQOzFR+AOgUTEWw83tDsrcSSC Zy4NPwPSmGQ4Hs3aew3ULu/G4gpRCGQcFlv6V5qXJyhN/cTqMNi9/0ay8dy8jl2NODIU CoZPzc2nGeYpacutJzUoPk8h5zMC5h+1hh55R7TIE5Cd8V3n7qQpVr6tgkq5C/8eRgax vdFDRaGvOyIqs8N8LHmbrkwP4QPPQqMU2SwC31tHzjAs7T9Ax9uGZjjArN9Y8olu2t65 PCeTZd5yoNVLUczMreNZJEQAcV6Kqryx0FoqkixxU7ILiW9lqx4bLYqGj4zORfXGRY+M s1Jg== X-Forwarded-Encrypted: i=1; AJvYcCVR2CVKLRUVKStdLfc1d0wQ3DP5mUm34o055JQsX3e9B1y71F+kuOSZ5VCi9ljbj7rAU0gQzAzpMA==@kvack.org X-Gm-Message-State: AOJu0YzV/29GUjTf7TfGCkS5Ksq7aX/rJ1odbEIG1utEHxKbXOjiS0iz EGrEhZVuRjRwEyIhYPdO2gf0HEiVxsr5DtG/8gnyGPMto5jbnQH8CUcvM7LFJlE= X-Gm-Gg: ASbGncv5vBRzcJHFZ22enp6iFfWErHKy1M2aUUWF3vHOIhWzkJndl3P7eYVq9nFkSXq g0Ir4Bq2gvNCubFDZjK6PVaKvm8no0XDVfKUdLPcZh25jMFnMm3WdVBjL7Z/33Mhx+ck/V0o7Zz i7GReNXhpgGhnehGqMSL2SHqTn/a+dMo0kvA1B+RE+4jM9FNW+/C/E9ipU4zF+aD5bdadhyyBQ6 Y5zvegqQwv0NBBhrxr3SfID5gaA+Gkh2lwfTHILKvSDc8dT2HP8HkqUSgrTHdArPTqDtbbM+ODH 3IC909t6UJvVZG53bt5tvWGzXyzMvepZoA== X-Google-Smtp-Source: AGHT+IGvvbEfuoj36uDT6iQfRvoVP/jlgaCQTj7ZxRBDmsIUR69H6fHHglU0zTLVf9g+bVwMLde9mw== X-Received: by 2002:a17:903:1251:b0:223:28a8:610b with SMTP id d9443c01a7336-22c412adbaamr10708135ad.14.1744870016272; Wed, 16 Apr 2025 23:06:56 -0700 (PDT) Received: from telecaster ([2601:602:8980:9170::9098]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-22c33f1d118sm25050395ad.86.2025.04.16.23.06.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Apr 2025 23:06:55 -0700 (PDT) Date: Wed, 16 Apr 2025 23:06:55 -0700 From: Omar Sandoval To: Ye Liu Cc: paulmck@kernel.org, Sweet Tea Dorminy , Andrew Morton , linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org, linux-mm@kvack.org, Ye Liu , linux-debuggers@vger.kernel.org Subject: Re: [PATCH] tools/drgn: Add script to display page state for a given PID and VADDR Message-ID: References: <20250415075024.248232-1-ye.liu@linux.dev> <20250415191414.a64de2d228ab5f43a5390acf@linux-foundation.org> <42f50a48-10da-4739-9e51-f865fbf04bdd@linux.dev> <098e977c-55cd-498b-bd36-725333c06210@dorminy.me> <7e45afc8-dde0-481a-b0bf-0237f551ebe0@paulmck-laptop> <665652ac-2e94-48b4-bf47-32870b823464@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <665652ac-2e94-48b4-bf47-32870b823464@linux.dev> X-Stat-Signature: adzdxswez4jzg9eipb16a3appxzeznmh X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 9378840003 X-Rspam-User: X-HE-Tag: 1744870017-607514 X-HE-Meta: U2FsdGVkX1+z9/nrp4+L2F02SQjTYARbh7NMVd70KfZ04YDJ/EbPTfDsBJ0/WB9F6T+xItzJTjkYLvzLadf5LNXBJvWpqurZ+SdPEZNWqru+biGN1p0SJWzrwHv/vVW4CW36oQ5lmh9bLCeBJgk1g6p+cRoPjLNNbpgXJj4cdN92pY44JyGbJ7UuUfrKY6UWM0ZVkvRvrnkbK++EGe6xuw3XXrl+D733aKNhPUaKiNcgHAll/70lnz3lPVIuReSiaWV9vSuFyQUfRhv/rOgVq2nUZ+AN+zQseqAzzwKGNRcBEpzKBHySuT+HaBKb5lNdxBsGG09YtL6jDpigRCSFV58OwbRNbaEPr/Zcq8dmK/0rmCDbWi9C3mpO7aVJq6vnAYdcwX5zRBw/9I0pPFXkL0HoNdv0OIhdRPXy5oBnoWeRyyLLOX/Z7ODZuYzuAUVBcz6nsdOzb3afu02PGVLWBKD5ZMEEUxVtUz8stI7dN+h1nublCNNmD9PCmNCoxljISy0L2ETUlB/CNhslLokvwwW5dC0qieFr48Gp55otIeGZ3WZigMdk9YpWas4nK87ubyhrFB1puZZmvss7yM86JUiNs671fC1fUncHdD/ogHYkeXgh1T41ZP/r9WTU86AXOWXAu6SUsyvEs1Dh/6mRY0EE7dW2neJIrX3xVaIhVTZerwudqKs3QsIA2RiLj5onqtj41Eug6c8M0EmpEfj3cnLMj3pgkQ4yfR0tytHh+OHX9O2rep88bCE9B/s6Xw2L1P2x+KmqM0NhplpPBab4ikieKbm/e/rAu1IuWXzIPyg+aGxk3T5R6cyBnwYC1yZHk0q7/m4i0MBsU4Nk/37qrC9kuNgfOeWoreCm0XjXXBgKhbMfHbfcoBMDSaIaUm8N41lnYeJiinv9lxtGMpYtlZ+j7aaV0WD+IMRj8HgwYH/5m1c5rGQL8eah5DJYomH8th8F/bPvG90yKyb4NYi Yef3shdL MemgkwYcEnnwVBN+Gwsq8JVRWMrfy8bEY7RvvxUTqDfqFdjG5fH3m7kgd6R8/xO2ZZcVCjWHgdRg2iP7KFcvaH+cKJTB1pTfsO3iUA8g8Yuj6OsWrq1qs0dgFaRpEhstL3YHa+EXHr6Mu1ug9w+LYlBC14OHP/vj0QIV6578dNoGE+8K4VPc2bzkfRIG+dJo7fSfM1EH0MlnOjThmNMtSLTLNxydRpu7auhvgOBlEKT0A3LkFqBwFKRwRAKR6QmkGve9YVSgxEetJ5SuJJ0bE3IoS9LmspMdarpTuif6HQb3b15mlBjrFeYlh/nrATQg3NK0XSfPdT2ciAWVQ9tTfthd15mJTxT4JoG5av0008u+OtpBi3MDZqiUaM4oVyo8r4ljxhivTQLieqVLRe9DsPooMXjibwALbMqSWKGKXEUdWG1h8H0bupOurtg3mE3MVK9dTTHg/vTLGJhxHcbRmpx9ZoA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.002064, 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, Apr 17, 2025 at 09:29:23AM +0800, Ye Liu wrote: > > 在 2025/4/16 12:02, Paul E. McKenney 写道: > > On Tue, Apr 15, 2025 at 11:28:41PM -0400, Sweet Tea Dorminy wrote: > >> > >> On 4/15/25 10:46 PM, Ye Liu wrote: > >>> 在 2025/4/16 10:14, Andrew Morton 写道: > >>>> On Tue, 15 Apr 2025 15:50:24 +0800 Ye Liu wrote: > >>>> > >>>>> From: Ye Liu > >>>>> > >>>>> Introduces a new drgn script, `show_page_info.py`, which allows users > >>>>> to analyze the state of a page given a process ID (PID) and a virtual > >>>>> address (VADDR). This can help kernel developers or debuggers easily > >>>>> inspect page-related information in a live kernel or vmcore. > >>>>> > >>>>> The script extracts information such as the page flags, mapping, and > >>>>> other metadata relevant to diagnosing memory issues. > >>>>> > >>>>> Currently, there is no specific maintainer entry for `tools/drgn/` in the > >>>>> MAINTAINERS file. Therefore, this patch is sent to the general kernel and > >>>>> tools mailing lists for review. > >>>> Help. My copy of linux has no tools/drgn/ > >>> I noticed that the current upstream Linux tree doesn't contain a > >>> `tools/drgn/` directory. > >>> > >>> I'm interested in contributing a drgn script tool as well. > >>> Given that this directory does not yet exist in mainline, where would > >>> be the appropriate place to add new drgn scripts? Would it make sense > >>> to create a new `tools/drgn/` directory, or is there a preferred > >>> location for such debugging scripts? > >>> > >>> Thanks, > >>> Ye > >> I believe the traditional thing to do with new drgn scripts is to add them > >> to the contrib directory in drgn via pull request: > >> https://github.com/osandov/drgn/blob/main/contrib/README.rst > > I have an RCU-related drgn script in tools/rcu, so maybe this one should > > go in tools/mm. > > > To determine the most appropriate place to submit this script, I looked > > into existing drgn-based tooling in the kernel tree. Several drgn scripts > have already been added under `tools/`, such as: > > - `tools/sched_ext/scx_show_state.py` > - `tools/cgroup/iocost_monitor.py` > - `tools/cgroup/memcg_slabinfo.py` > - `tools/writeback/wb_monitor.py` > - `tools/rcu/rcu-cbs.py` > - `tools/workqueue/wq_dump.py` > - `tools/workqueue/wq_monitor.py` > > Given this precedent, I believe it would be reasonable to place > `show_page_info.py` under `tools/mm/`, since it's focused on memory > subsystem internals and would follow a similar organizational pattern > to the above. > > I'd appreciate any input on whether this is a suitable direction. > I'm happy to send the script for review once the location is agreed upon. > > Thanks,   > > Ye Liu Hi, The drgn repository and the kernel tools directory are both valid places to put drgn scripts, and it's ultimately up to you where you'd prefer to put it. Here are some factors to consider, though: 1. Reusability: if your script is very generic and would be widely useful, the ideal is to add it as a helper to drgn upstream. For scripts that are less generic but could still be useful to many people, I'd personally prefer for them to go into the drgn repository's tools or contrib directories. At the other extreme, if your script is only useful to a handful of developers of a specific subsystem, the kernel tools directory makes more sense. 2. Kernel version coupling: there are a couple of options for dealing with kernel changes that require drgn scripts to be updated (e.g., struct member renames, data structure changes). Scripts in the kernel tools directory tend to only handle the current version. This is simpler, but it also means that sometimes you can't use features from a new version of the script on old kernels. On the other hand, the drgn repository supports every kernel version that's still meaningfully deployed. This can complicate scripts with version-dependent logic, but it means you can always use the latest and greatest features on any kernel version. I prefer the latter approach, but the choice is yours (except for drgn helpers upstream, which are required to support all kernel versions). 3. Maintainership: who wants to own the script? A lot of the current drgn scripts in the kernel tools directory are written and maintained by the relevant subsystem maintainers, so it's a no-brainer for them to own it without any involvement from the drgn project. It's not as obvious for other contributors. If the subsystem maintainer is willing to own a drgn script in the kernel repo, then I won't complain. I'm willing to take just about anything for the drgn repository's contrib directory, and I'm slightly more selective for helpers and tools. All that being said, your script looks pretty widely useful, so I think it'd make sense in the drgn repository's contrib directory (or even the tools directory if you want to make it a full-fledged tool with test cases, support for all kernel versions, documentation, etc., but contrib is fine). Thanks, Omar