Hi Gregory, On Mon, Jun 16, 2025 at 12:43 PM Gregory Price <gourry@xxxxxxxxxx> wrote: > > On Mon, Jun 16, 2025 at 09:16:55AM -0500, Bijan Tabatabai wrote: > > > > > > Which, you also have during the rmap walk. > > > > There is another subtle dependency in get_vma_policy. > > It first checks if a VMA policy exists, and if it doesn't, it uses the > > task policy of the current task, which doesn't make sense when called > > by a kdamond thread. > > > > However, I don't think this will change what seems to be our consensus > > of adding a new helper function. > > > > Hate to interject here, but this gets worse the further you dig in. The > mempolicy interface as a whole has many, many, many hidden references to > current->mempolicy and current->mems_allowed. External interface > references to a task or vma mempolicy is a problem i explored somewhat > extensively when I prototyped `set_mempolicy2()`. It did not go well. > > Generally, mempolicy is not well structured to allow external actors on > a task's mempolicy. Accessing a task's mempolicy requires operating in > a task's context or at least taking a reference on that task's mempolicy > (which requires taking the task_struct lock). Good point, I didn't take the lock in the second patch. Also, this made me realize I need to make sure there isn't a race condition where a task exits after getting a pointer to its task_struct from mm->owner. > I will just say that mempolicy is *extremely* current-task centric - and > very much allocation-time centric (i.e. the internal workings don't > really want to consider migration all that much). You'll probably find > that this project requires rethinking mempolicy's external interfaces in > general (which is sorely needed anyway). > > I think this path to modifying mempolicy to support DAMON is a bit > ambitious for where mempolicy is at the moment. You may be better off > duplicating the interleave-weight logic and making some helper functions > to get the weight data, and then coming back around to generalize it > later. This may be true, but I think I will be able to avoid a lot of this nastiness with what I need. I am going to try with the mempolicy approach for the next revision, but if I get too much resistance, I will probably switch to this approach. Thanks, Bijan
