Hi-- On 9/26/22 07:08, Michal Hocko wrote: > On Mon 26-09-22 20:53:19, Zhongkun He wrote: >>> [Cc linux-api - please do so for any patches making/updating >>> kernel<->user interfaces] >>> >>> >>> On Mon 26-09-22 17:10:33, hezhongkun wrote: >>>> From: Zhongkun He <hezhongkun.hzk@xxxxxxxxxxxxx> >>>> >>>> /proc/pid/mempolicy can be used to check and adjust the userspace task's >>>> mempolicy dynamically.In many case, the application and the control plane >>>> are two separate systems. When the application is created, it doesn't know >>>> how to use memory, and it doesn't care. The control plane will decide the >>>> memory usage policy based on different reasons.In that case, we can >>>> dynamically adjust the mempolicy using /proc/pid/mempolicy interface. >>> >>> Is there any reason to make it procfs interface rather than pidfd one? >> >> Hi michal, thanks for your reply. >> >> I just think that it is easy to display and adjust the mempolicy using >> procfs. But it may not be suitable, I will send a pidfd_set_mempolicy patch >> later. > > proc interface has many usability issues. That is why pidfd has been > introduced. So I would rather go with the pidfd interface than repeating > old proc API mistakes. Sorry, I'm not familiar with the pidfd interface and I can't find any documentation on it. Is there some? Can I 'cat' or 'grep' in the pidfd interface? >> Btw.in order to add per-thread-group mempolicy, is it possible to add >> mempolicy in mm_struct? > > I dunno. This would make the mempolicy interface even more confusing. > Per mm behavior makes a lot of sense but we already do have per-thread > semantic so I would stick to it rather than introducing a new semantic. > > Why is this really important? Thanks. -- ~Randy
