> > Hi ZhongKun! > > I actually just sent out a more general RFC to mempolicy updates that > discuss this more completely: > > https://lore.kernel.org/linux-mm/ZWezcQk+BYEq%2FWiI@xxxxxxxxxxxx/ > OK. > and another post on even more issues with pidfd modifications to vma > mempolicies: > > https://lore.kernel.org/linux-mm/ZWYsth2CtC4Ilvoz@xxxxxxxxxxxx/ > > We may have to slow-walk the changes to vma policies due to there being > many more hidden accesses to (current) than expected. It's a rather > nasty rats nest of mempolicy-vma-cpusets-shmem callbacks that obscure > these current-task accesses, it will take time to work through. > Got it, thanks. It's more complicated than I thought. > As for hot-path reference counting - we may need to change the way > mempolicy is managed, possibly we could leverage RCU to manage mempolicy > references in the hot path, rather than using locks. In this scenario, > we would likely need to change the way the default policy is applied > (maybe not, I haven't fully explored it). > RCU may have a long time in the read-side critical section. We should probably replace the atomic_t refcnt with percpu_ref in mempolicy(also suggested by Michal), but refactoring work involves a lot of code. A simple way is to use task_work to release the mempolicy which may be used by alloc_pages(). But it doesn't have a direct result. > Do you have thoughts on this? Would very much like additional comments > before I go through the refactor work. > > Regards, > Gregory
