Michal Hocko <mhocko@xxxxxxxx> writes: > On Thu 27-10-22 14:47:22, Huang, Ying wrote: >> Michal Hocko <mhocko@xxxxxxxx> writes: > [...] >> > I can imagine workloads which wouldn't like to get their memory demoted >> > for some reason but wouldn't it be more practical to tell that >> > explicitly (e.g. via prctl) rather than configuring cpusets/memory >> > policies explicitly? >> >> If my understanding were correct, prctl() configures the process or >> thread. > > Not necessarily. There are properties which are per adddress space like > PR_[GS]ET_THP_DISABLE. This could be very similar. > >> How can we get process/thread configuration at demotion time? > > As already pointed out in previous emails. You could hook into > folio_check_references path, more specifically folio_referenced_one > where you have all that you need already - all vmas mapping the page and > then it is trivial to get the corresponding vm_mm. If at least one of > them has the flag set then the demotion is not allowed (essentially the > same model as VM_LOCKED). Got it! Thanks for detailed explanation. One bit may be not sufficient. For example, if we want to avoid or control cross-socket demotion and still allow demoting to slow memory nodes in local socket, we need to specify a node mask to exclude some NUMA nodes from demotion targets. >From overhead point of view, this appears similar as that of VMA/task memory policy? We can make mm->owner available for memory tiers (CONFIG_NUMA && CONFIG_MIGRATION). The advantage is that we don't need to introduce new ABI. I guess users may prefer to use `numactl` than a new ABI? Best Regards, Huang, Ying
