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. > 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? -- Michal Hocko SUSE Labs
