linux-kernel - Re: Re: [PATCH v2 0/9] Introduce Data Access MONitor (DAMON)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200128120033.27016-1-sjpark@amazon.com>
Date:   Tue, 28 Jan 2020 13:00:33 +0100
From:   <sjpark@...zon.com>
To:     unlisted-recipients:; (no To-header on input)
CC:     <sjpark@...zon.com>, <akpm@...ux-foundation.org>,
        SeongJae Park <sjpark@...zon.de>, <sj38.park@...il.com>,
        <acme@...nel.org>, <amit@...nel.org>, <brendan.d.gregg@...il.com>,
        <corbet@....net>, <dwmw@...zon.com>, <mgorman@...e.de>,
        <rostedt@...dmis.org>, <kirill@...temov.name>,
        <brendanhiggins@...gle.com>, <colin.king@...onical.com>,
        <minchan@...nel.org>, <vdavydov.dev@...il.com>,
        <vdavydov@...allels.com>, <linux-mm@...ck.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Ingo Molnar" <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        "Alexander Shishkin" <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: Re: [PATCH v2 0/9] Introduce Data Access MONitor (DAMON)

To: Qian Cai <cai@....pw>

On Tue, 28 Jan 2020 06:20:29 -0500 Qian Cai <cai@....pw> wrote:

> 
> 
> > On Jan 28, 2020, at 5:50 AM, sjpark@...zon.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