On Fri, 4 Feb 2022, Jonghyeon Kim wrote: > > > This patch allows kdamond thread to select watermark options for monitoring > > > specific node or whole system free memory. > > > > Why only specific NUMA node or whole system, instead of each NUMA node? Are > > you running DARC for only specific NUMA node? If that's the case, I think > > implementing your own DAMON-based policy in user space might be a better > > choice. For example, you could implement and use a user-space daemon that > > monitors free memory ratio of each NUMA node and adjusts the watermarks. > > > > I have tested DAMON_RECLAIM for each NUMA node by using a module. But, I felt > that the goal of DAMON_RECLAIM is dealing with the entire system memory or > specific monitoring regions by using module parameters. So, I hoped to add more > options for DAMON_RECLAIM on the NUMA system. > > Another thing I considered is the problem of correlation between NUMA node range > and monitoring start/end addresses, such as "What if we monitor target that > spans multiple nodes?". > In that case, I guess we have to decide the policy for watermarks. > > > Hope I'm not making you get me wrong. You found the important limitation of > > DAMON_RECLAIM, thank you! I really hope DAMON_RECLAIM to evolve to handle the > > case. I'm just saying this patch looks like specialized for your special case, > > and there could be a better approach for that. > > > > If you agree that each NUMA node is able to have its own DAMON_RECLAIM daemon > threads, I will add that codes in the next patch. > It seems like one DAMON context per NUMA node is required for this, no? In other words, since each context has its own set of memory regions that it monitors and set of watermarks that it must abide by, if we want per NUMA node proactive reclaim then each node must have its own context that is coordinated by userspace if we want to do system-wide proactive reclaim.
