linux-kernel - Re: [PATCH 1/4] mm/damon/dbgfs: Implement recording feature

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]

Date:   Sun, 10 Oct 2021 15:01:40 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     SeongJae Park <sj@...nel.org>
Cc:     Jonathan.Cameron@...wei.com, amit@...nel.org,
        benh@...nel.crashing.org, corbet@....net, david@...hat.com,
        dwmw@...zon.com, elver@...gle.com, foersleo@...zon.de,
        gthelen@...gle.com, markubo@...zon.de, rientjes@...gle.com,
        shakeelb@...gle.com, shuah@...nel.org, linux-damon@...zon.com,
        linux-mm@...ck.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] mm/damon/dbgfs: Implement recording feature

On Fri,  8 Oct 2021 09:45:06 +0000 SeongJae Park <sj@...nel.org> wrote:

> The user space can get the monitoring results via the 'damon_aggregated'
> tracepoint event.  For simplicity and brevity, the tracepoint events
> have some duplicated information such as 'target_id' and 'nr_regions',
> though.  As a result, its size is greater than really needed.  Also,
> dealing with the tracepoint could be complex for some simple use cases.
> To provide a way for getting more efficient and simple monitoring
> results to user space, this commit implements 'recording' feature in
> 'damon-dbgfs'.
> 
> The feature is exported to the user space via a new debugfs file named
> 'record', which is located in '<debugfs>/damon/' directory.  The file
> allows users to record monitored access patterns in a regular binary
> file in a simple format.

Binary files are troublesome.

Is the format of this file documented anywhere?

I assume that the file's contents will have different representations
depending on host endianness and word size and I further assume that
the provided python script won't handle this very well?

>  The recorded results are first written in an
> in-memory buffer and flushed to a file in batch.  Users can get and set
> the size of the buffer and the path to the result file by reading from
> and writing to the 'record' file.  For example, below commands set the
> buffer to be 4 KiB and the result to be saved in '/damon.data'.

> With a simple test workload[1], recording the tracepoint event using
> 'perf-record' results in 1.7 MiB 'perf.data' file.  When the access
> pattern is recorded via this feature, the size is reduced to 264 KiB. 
> Also, the resulting record file is simple enough to be manipulated by a
> small (100 lines of code) python script which will be introduced by a
> following commit ("selftests/damon: Test recording feature").

How useful and important is this?  I mean, is it tremendously better or
is it a little bit nice to have?  A description of the overall benefit
to DAMON users would be useful in helping others to understand the
benefit of this change.