Re: [PATCH 1/4] mm/damon/dbgfs: Implement recording feature
flat view
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2021-10-11 21:02:40
Also in:
linux-doc, lkml
On Mon, 11 Oct 2021 09:30:57 +0000 SeongJae Park [off-list ref] wrote:
Hello Andrew, Thank you for great questions! On Sun, 10 Oct 2021 15:01:40 -0700 Andrew Morton [off-list ref] wrote:quoted
On Fri, 8 Oct 2021 09:45:06 +0000 SeongJae Park [off-list ref] wrote:quoted
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/ (local) [2] https://github.com/awslabs/damo/blob/v0.0.5/_damon_result.py#L38quoted
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.