From: <sjpark@amazon.com> To: unlisted-recipients:; (no To-header on input) Cc: <sjpark@amazon.com>, <akpm@linux-foundation.org>, SeongJae Park <sjpark@amazon.de>, <sj38.park@gmail.com>, <acme@kernel.org>, <amit@kernel.org>, <brendan.d.gregg@gmail.com>, <corbet@lwn.net>, <dwmw@amazon.com>, <mgorman@suse.de>, <rostedt@goodmis.org>, <kirill@shutemov.name>, <brendanhiggins@google.com>, <colin.king@canonical.com>, <minchan@kernel.org>, <vdavydov.dev@gmail.com>, <vdavydov@parallels.com>, <linux-mm@kvack.org>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, "Ingo Molnar" <mingo@redhat.com>, Mark Rutland <mark.rutland@arm.com>, "Alexander Shishkin" <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org> Subject: Re: Re: [PATCH v2 0/9] Introduce Data Access MONitor (DAMON) Date: Tue, 28 Jan 2020 13:00:33 +0100 [thread overview] Message-ID: <20200128120033.27016-1-sjpark@amazon.com> (raw) In-Reply-To: <41BBD985-4B3D-4F87-B69D-D8CFE6EC0EBE@lca.pw> (raw) To: Qian Cai <cai@lca.pw> On Tue, 28 Jan 2020 06:20:29 -0500 Qian Cai <cai@lca.pw> wrote: > > > > On Jan 28, 2020, at 5:50 AM, sjpark@amazon.com wrote: > > > > For the comments from perf maintainers, I added Steven Rostedt and Arnaldo > > Carvalho de Melo first, but I might missed someone. If you recommend some more > > people, I will add them to recipients. > > > > I made DAMON as a new subsystem because I think no existing subsystem fits well > > to be a base of DAMON, due to DAMON's unique goals and mechanisms described > > below in the original cover letter. > > > > The existing subsystem that most similar to DAMON might be 'mm/page_idle.c'. > > However, there are many conceptual differences with DAMON. One biggest > > difference I think is the target. 'page_idle' deals with physical page frames > > while DAMON deals with virtual address of specific processes. > > > > Nevertheless, if you have some different opinion, please let me know. > > I thought everyone should know to go to the MAINTAINERS file and search PERFORMANCE EVENTS SUBSYSTEM. I worried whether it could be a bother to send the mail to everyone in the section, but seems it was an unnecessary worry. Adding those to recipients. You can get the original thread of this patchset from https://lore.kernel.org/linux-mm/20200128085742.14566-1-sjpark@amazon.com/ > > It might be difficult but there is a perf subcommand for some subsystems like sched: tracing/measuring of scheduler actions and latencies. Seems like you are suggesting to implement the DAMON's core logic as a subcommand of perf in user space. Because DAMON's logic inherently require frequent interaction with privileged features that need to be done inside the kernel space, I think it will incur frequent context switch and might not fulfill its performance requirement. As far as I understand, we normally add a data source in the kernel and implement sophisticated handlings or visualizations in the perf. I think DAMON is a source of a new primitive data (data access pattern). Thanks, SeongJae Park
WARNING: multiple messages have this Message-ID (diff)
From: <sjpark@amazon.com> Cc: <sjpark@amazon.com>, <akpm@linux-foundation.org>, SeongJae Park <sjpark@amazon.de>, <sj38.park@gmail.com>, <acme@kernel.org>, <amit@kernel.org>, <brendan.d.gregg@gmail.com>, <corbet@lwn.net>, <dwmw@amazon.com>, <mgorman@suse.de>, <rostedt@goodmis.org>, <kirill@shutemov.name>, <brendanhiggins@google.com>, <colin.king@canonical.com>, <minchan@kernel.org>, <vdavydov.dev@gmail.com>, <vdavydov@parallels.com>, <linux-mm@kvack.org>, <linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, "Ingo Molnar" <mingo@redhat.com>, Mark Rutland <mark.rutland@arm.com>, "Alexander Shishkin" <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org> Subject: Re: Re: [PATCH v2 0/9] Introduce Data Access MONitor (DAMON) Date: Tue, 28 Jan 2020 13:00:33 +0100 [thread overview] Message-ID: <20200128120033.27016-1-sjpark@amazon.com> (raw) In-Reply-To: <41BBD985-4B3D-4F87-B69D-D8CFE6EC0EBE@lca.pw> (raw) To: Qian Cai <cai@lca.pw> On Tue, 28 Jan 2020 06:20:29 -0500 Qian Cai <cai@lca.pw> wrote: > > > > On Jan 28, 2020, at 5:50 AM, sjpark@amazon.com wrote: > > > > For the comments from perf maintainers, I added Steven Rostedt and Arnaldo > > Carvalho de Melo first, but I might missed someone. If you recommend some more > > people, I will add them to recipients. > > > > I made DAMON as a new subsystem because I think no existing subsystem fits well > > to be a base of DAMON, due to DAMON's unique goals and mechanisms described > > below in the original cover letter. > > > > The existing subsystem that most similar to DAMON might be 'mm/page_idle.c'. > > However, there are many conceptual differences with DAMON. One biggest > > difference I think is the target. 'page_idle' deals with physical page frames > > while DAMON deals with virtual address of specific processes. > > > > Nevertheless, if you have some different opinion, please let me know. > > I thought everyone should know to go to the MAINTAINERS file and search PERFORMANCE EVENTS SUBSYSTEM. I worried whether it could be a bother to send the mail to everyone in the section, but seems it was an unnecessary worry. Adding those to recipients. You can get the original thread of this patchset from https://lore.kernel.org/linux-mm/20200128085742.14566-1-sjpark@amazon.com/ > > It might be difficult but there is a perf subcommand for some subsystems like sched: tracing/measuring of scheduler actions and latencies. Seems like you are suggesting to implement the DAMON's core logic as a subcommand of perf in user space. Because DAMON's logic inherently require frequent interaction with privileged features that need to be done inside the kernel space, I think it will incur frequent context switch and might not fulfill its performance requirement. As far as I understand, we normally add a data source in the kernel and implement sophisticated handlings or visualizations in the perf. I think DAMON is a source of a new primitive data (data access pattern). Thanks, SeongJae Park
next prev parent reply other threads:[~2020-01-28 12:01 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-28 8:57 [PATCH v2 0/9] Introduce Data Access MONitor (DAMON) sjpark 2020-01-28 8:57 ` [PATCH v2 1/9] mm: " sjpark 2020-01-28 16:06 ` Randy Dunlap 2020-01-28 16:09 ` sjpark 2020-01-30 23:58 ` Brendan Higgins 2020-01-30 23:58 ` Brendan Higgins 2020-01-31 4:38 ` SeongJae Park 2020-01-28 8:57 ` [PATCH v2 2/9] mm/damon: Implement region based sampling sjpark 2020-01-28 8:57 ` [PATCH v2 3/9] mm/damon: Adaptively adjust regions sjpark 2020-01-28 8:57 ` [PATCH v2 4/9] mm/damon: Apply dynamic memory mapping changes sjpark 2020-01-28 8:59 ` [PATCH v2 5/9] mm/damon: Add debugfs interface sjpark 2020-01-28 9:00 ` [PATCH v2 6/9] mm/damon: Add minimal user-space tools sjpark 2020-01-31 0:02 ` Brendan Higgins 2020-01-31 0:02 ` Brendan Higgins 2020-01-31 4:44 ` SeongJae Park 2020-02-01 8:52 ` SeongJae Park 2020-01-28 9:00 ` [PATCH v2 7/9] Documentation/admin-guide/mm: Add a document for DAMON sjpark 2020-01-28 9:01 ` [PATCH v2 8/9] mm/damon: Add kunit tests sjpark 2020-01-31 0:14 ` Brendan Higgins 2020-01-31 0:14 ` Brendan Higgins 2020-01-31 4:55 ` SeongJae Park 2020-01-28 9:01 ` [PATCH v2 9/9] mm/damon: Add a tracepoint for result buffer writing sjpark 2020-01-28 10:20 ` [PATCH v2 0/9] Introduce Data Access MONitor (DAMON) Qian Cai 2020-01-28 10:49 ` sjpark 2020-01-28 11:20 ` Qian Cai 2020-01-28 12:00 ` sjpark [this message] 2020-01-28 12:00 ` sjpark 2020-01-29 12:56 ` Peter Zijlstra 2020-01-29 14:37 ` sjpark 2020-01-29 18:07 ` Peter Zijlstra 2020-01-29 19:06 ` SeongJae Park 2020-01-29 19:36 ` Peter Zijlstra 2020-01-29 19:59 ` 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=20200128120033.27016-1-sjpark@amazon.com \ --to=sjpark@amazon.com \ --cc=acme@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=amit@kernel.org \ --cc=brendan.d.gregg@gmail.com \ --cc=brendanhiggins@google.com \ --cc=colin.king@canonical.com \ --cc=corbet@lwn.net \ --cc=dwmw@amazon.com \ --cc=jolsa@redhat.com \ --cc=kirill@shutemov.name \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mark.rutland@arm.com \ --cc=mgorman@suse.de \ --cc=minchan@kernel.org \ --cc=mingo@redhat.com \ --cc=namhyung@kernel.org \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=sj38.park@gmail.com \ --cc=sjpark@amazon.de \ --cc=vdavydov.dev@gmail.com \ --cc=vdavydov@parallels.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.