On Thu, 21 Nov 2024 14:58:52 +0000 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Thu, 21 Nov 2024 09:24:43 -0500 > Gregory Price <gourry@xxxxxxxxxx> wrote: > > > On Thu, Nov 21, 2024 at 10:18:41AM +0000, Jonathan Cameron wrote: [...] > Just working out how to tune the hardware to grab useful data is going > to take a while to figure out, let alone doing anything much with it. > > Without care you won't get a meaningful signal for what is actually > hot out of the box. Lots of reasons why including: > a) Exhaustion of tracking resources, due to looking at too large a window > or for too long. Will probably need some form of auto updating of > what is being scanning (coarse to fine might work though I'm doubtful, > scanning across small regions maybe). > b) Threshold too high, no detections. > c) Threshold too low, everything hot. > d) Wrong timescales. Hot is not a well defined thing. > e) Hardware that won't do tracking at fine enough granularity. Similar questions can be raised to general hotness monitoring including that for DAMON. I'm trying to summarize[1] rules of thumbs for DAMON tuning based on my humble experiences. Once it is done, I will further try automations of tunings. In future, hopefully DAMON can be extended to utilize CXL hotness monitoring unit as low level primitive for access check. Then, the guidance and automation of DAMON tuning could be just applied. Note that I'm not saying DAMON should be the only way to utilize CXL hotness monitoring unit. I'm saying DAMON could be one of the ways :) [1] https://lore.kernel.org/20241108232536.73843-1-sj@xxxxxxxxxx Thanks, SJ [...]
