[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20211011140235.f75b842f861b730c53e4b19c@linux-foundation.org>
Date: Mon, 11 Oct 2021 14:02:35 -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 Mon, 11 Oct 2021 09:30:57 +0000 SeongJae Park <sj@...nel.org> wrote:
> Hello Andrew,
>
>
> Thank you for great questions!
>
> On Sun, 10 Oct 2021 15:01:40 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > 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?
>
> No. I intended the Python script in the following patch[1] and the user space
> tool[2] to be used as such documents. I will write up one before the next
> spin.
>
> [1] https://lore.kernel.org/linux-mm/20211008094509.16179-3-sj@kernel.org/
> [2] https://github.com/awslabs/damo/blob/v0.0.5/_damon_result.py#L38
>
> >
> > 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?
>
> You're right. I will make the script properly handle the cases in the next
> spin.
Well, rather than messing with the different file formats, you could
make the binary file machine-independent. Decide on the endianness and
word size, implement them and document them. Things like cpu_to_le32
are zero-cost on little-endian machines.
Powered by blists - more mailing lists