From: SeongJae Park <sj@kernel.org>
To: xhao@linux.alibaba.com
Cc: SeongJae Park <sj@kernel.org>,
akpm@linux-foundation.org, corbet@lwn.net,
skhan@linuxfoundation.org, rientjes@google.com,
linux-damon@amazon.com, linux-mm@kvack.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/12] mm/damon: Implement a minimal stub for sysfs-based DAMON interface
Date: Fri, 25 Feb 2022 08:10:24 +0000 [thread overview]
Message-ID: <20220225081024.1979-1-sj@kernel.org> (raw)
In-Reply-To: <66331451-48d8-6658-cdce-6e79df27ae5e@linux.alibaba.com>
Hi Xin,
On Fri, 25 Feb 2022 15:21:05 +0800 xhao@linux.alibaba.com wrote:
> Hi, SeongJae:
>
> On 2/23/22 11:20 PM, SeongJae Park wrote:
> > DAMON's debugfs-based user interface served very well, so far. However,
> > it unnecessarily depends on debugfs, while DAMON is not aimed to be used
> > for only debugging. Also, the interface receives multiple values via
> > one file. For example, schemes file receives 18 values separated by
> > white spaces. As a result, it is ineffient, hard to be used, and
> > difficult to be extended. Especially, keeping backward compatibility of
> > user space tools is getting only challenging. It would be better to
> > implement another reliable and flexible interface and deprecate the
> > debugfs interface in long term.
> >
> > To this end, this commit implements a stub of a part of the new user
> > interface of DAMON using sysfs. Specifically, this commit implements
> > the sysfs control parts for virtual address space monitoring.
> >
> > More specifically, the idea of the new interface is, using directory
> > hierarchies and making one file for one value. The hierarchy that this
> > commit is introducing is as below. In the below figure,
> > parents-children relations are represented with indentations, each
> > directory is having ``/`` suffix, and files in each directory are
> > separated by comma (",").
> >
> > /sys/kernel/mm/damon/admin
> > │ kdamonds/nr
> > │ │ 0/state,pid
> > │ │ │ contexts/nr
> > │ │ │ │ 0/operations
> > │ │ │ │ │ monitoring_attrs/
> > │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
> > │ │ │ │ │ │ nr_regions/min,max
> > │ │ │ │ │ targets/nr
> > │ │ │ │ │ │ 0/pid
> > │ │ │ │ │ │ ...
> > │ │ │ │ ...
> > │ │ ...
>
> >
> > Writing a number <N> to each 'nr' file makes directories of name <0> to
> > <N-1> in the directory of the 'nr' file. That's all this commit does.
> > Writing proper values to relevant files will construct the DAMON
> > contexts, and writing a special keyword, 'on', to 'state' files for each
> > kdamond will ask DAMON to start the constructed contexts.
> >
> > For a short example, using below commands for
> > monitoring virtual address spaces of a given workload is imaginable:
> >
> > # cd /sys/kernel/mm/damon/admin/
> > # echo 1 > kdamonds/nr
> > # echo 1 > kdamonds/0/contexts/nr
> > # echo vaddr > kdamonds/0/contexts/0/damon_type
> > # echo 1 > kdamonds/0/contexts/0/targets/nr
> > # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid
> > # echo on > kdamonds/0/state
>
> I do some test about the sys interface, like this:
>
> [root@rt2k03395 0]# tree
> .
> ├── contexts
> │ ├── 0
> │ │ ├── monitoring_attrs
> │ │ │ ├── intervals
> │ │ │ │ ├── aggr_us
> │ │ │ │ ├── sample_us
> │ │ │ │ └── update_us
> │ │ │ └── nr_regions
> │ │ │ ├── max
> │ │ │ └── min
> │ │ ├── operations
> │ │ ├── schemes
> │ │ │ └── nr
> │ │ └── targets
> │ │ ├── 0
> │ │ │ ├── pid
> │ │ │ └── regions
> │ │ │ ├── 0
> │ │ │ │ ├── end
> │ │ │ │ └── start
> │ │ │ ├── 1
> │ │ │ │ ├── end
> │ │ │ │ └── start
> │ │ │ ├── 10
> │ │ │ │ ├── end
> │ │ │ │ └── start
> │ │ │ ├── 11
> │ │ │ │ ├── end
> │ │ │ │ └── start
> │ │ │ ├── 12
>
> cd regions/
> [root@rt2k03395 regions]# ls
> 0 10 12 14 16 18 2 21 23 25 27 29 30 32 34 36 38 4
> 41 43 45 47 49 6 8 nr
> 1 11 13 15 17 19 20 22 24 26 28 3 31 33 35 37 39 40
> 42 44 46 48 5 7 9
> [root@rt2k03395 regions]# cd 44/cat *
>
> [root@rt2k03395 regions/44]# cat *
> 0 0
>
> I'm skeptical about the number regions ? And after manually setting the
> number of nr, the processing of
>
> "start" and "end" will be very troublesome,I guess you might want to do
> some special region addresses,
>
> such as hot or cold region, Is that true ?
The purpose of regions/ directory is for supporting the initial monitoring
regions feature of debugfs, which is optional for virtual address spaces
monitoring, but essential for physical address space monitoing. If you need to
monitor only virtual address spaces, you don't need to populate the directory.
In a future, we could add nr_accesses and age files under each region directory
and apply the monitoring results there.
> But I think you need to think
> about how do you deal with too many
>
> uncontacted reigons that need to be done.
Sysfs interface is not aimed to be used by human hand but user space tools, and
we provide a reference tool, damo. Please consider using that or implement
your own. You could also refer to my reply to your other email for this point:
https://lore.kernel.org/linux-mm/20220225080513.1908-1-sj@kernel.org/
Thanks,
SJ
[...]
next prev parent reply other threads:[~2022-02-25 8:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 15:20 [PATCH 00/12] Introduce DAMON sysfs interface SeongJae Park
2022-02-23 15:20 ` [PATCH 01/12] mm/damon/core: Allow non-exclusive DAMON start/stop SeongJae Park
2022-02-23 15:20 ` [PATCH 02/12] mm/damon/core: Add number of each enum type values SeongJae Park
2022-02-23 15:20 ` [PATCH 03/12] mm/damon: Implement a minimal stub for sysfs-based DAMON interface SeongJae Park
2022-02-23 16:09 ` Greg KH
2022-02-23 16:45 ` SeongJae Park
2022-02-23 17:13 ` SeongJae Park
2022-02-23 18:33 ` Greg KH
2022-02-23 19:03 ` SeongJae Park
2022-02-25 7:21 ` xhao
2022-02-25 8:10 ` SeongJae Park [this message]
2022-02-23 15:20 ` [PATCH 04/12] mm/damon/sysfs: Link DAMON for virtual address spaces monitoring SeongJae Park
2022-02-23 15:20 ` [PATCH 05/12] mm/damon/sysfs: Support physical address space monitoring SeongJae Park
2022-02-23 15:20 ` [PATCH 06/12] mm/damon/sysfs: Support DAMON-based Operation Schemes SeongJae Park
2022-02-23 15:20 ` [PATCH 07/12] mm/damon/sysfs: Support DAMOS quotas SeongJae Park
2022-02-23 15:20 ` [PATCH 08/12] mm/damon/sysfs: Support schemes prioritization weights SeongJae Park
2022-02-23 15:20 ` [PATCH 09/12] mm/damon/sysfs: Support DAMOS watermarks SeongJae Park
2022-02-23 15:20 ` [PATCH 10/12] mm/damon/sysfs: Support DAMOS stats SeongJae Park
2022-02-23 15:20 ` [PATCH 11/12] selftests/damon: Add a test for DAMON sysfs interface SeongJae Park
2022-02-23 15:20 ` [PATCH 12/12] Docs/admin-guide/mm/damon/usage: Document " SeongJae Park
2022-02-23 16:07 ` [PATCH 00/12] Introduce " Greg KH
2022-02-23 16:44 ` SeongJae Park
2022-02-25 7:32 ` xhao
2022-02-25 8:05 ` SeongJae Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220225081024.1979-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-damon@amazon.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=skhan@linuxfoundation.org \
--cc=xhao@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox