On Tue, Aug 18, 2020 at 12:25 AM SeongJae Park <sjpark@xxxxxxxxxx> wrote: > > From: SeongJae Park <sjpark@xxxxxxxxx> > > Changes from Previous Version > ============================= > > - Use 42 as the fake target id for paddr instead of -1 > - Fix a typo > > Introduction > ============ > > DAMON[1] programming interface users can extend DAMON for any address space by > configuring the address-space specific low level primitives with appropriate > ones including their own implementations. However, because the implementation > for the virtual address space is only available now, the users should implement > their own for other address spaces. Worse yet, the user space users who rely > on the debugfs interface and user space tool, cannot implement their own. > > This patchset implements another reference implementation of the low level > primitives for the physical memory address space. With this change, hence, the > kernel space users can monitor both the virtual and the physical address spaces > by simply changing the configuration in the runtime. Further, this patchset > links the implementation to the debugfs interface and the user space tool for > the user space users. > > Note that the implementation supports only the user memory, as same to the idle > page access tracking feature. > > [1] https://lore.kernel.org/linux-mm/20200706115322.29598-1-sjpark@xxxxxxxxxx/ > I am still struggling to find the benefit of this feature the way it is implemented i.e. region based physical address space monitoring. What exactly am I supposed to do for a given hot (or cold) physical region? In a containerized world, that region can contain pages from any cgroup. I can not really do anything about the accesses PHY-DAMON provides me for a region. Now if you give me per-page information that would be useful as I can at least get per-cgroup accesses (idle or re-use data) but that would be as costly as Page Idle Tracking.
