On Fri 13-01-23 17:20:39, Michal Hocko wrote: > On Mon 05-12-22 00:14:29, Zhongkun He wrote: > > All vma manipulation is somewhat protected by a down_read on > > mmap_lock, so vma mempolicy is clear to obtain a reference. > > But there is no locking in process context and have a mix > > of reference counting and per-task requirements which is rather > > subtle and easy to get wrong. > > > > we would have get_vma_policy() always returning a reference > > counted policy, except for static policy. For better performance, > > we replace atomic_t ref with percpu_ref in mempolicy, which is > > usually the performance bottleneck in hot path. > > > > This series adjust the reference of mempolicy in process context, > > which will be protected by RCU in read hot path. Besides, > > task->mempolicy is also protected by task_lock(). Percpu_ref > > is a good way to reduce cache line bouncing. > > > > The mpol_get/put() can just increment or decrement the local > > counter. Mpol_kill() must be called to initiate the destruction > > of mempolicy. A mempolicy will be freed when the mpol_kill() > > is called and the reference count decrese to zero. > > This is really hard to follow. Without having the context from previous > discussions I would be completely lost. Please structure your cover > letter but also other patch in general in the form: > - what is the problem you would like to deal with > - want to introduce pidfd_set_mempolicy because XYZ > - what stands in the way > - mempolicy objects access constrains (reliance on operating in > the current context) > - reference counting needs to be unconditional > - why regular reference counting is not sufficient (performance) > - what is this patchset proposing > - per cpu reference counting > - how is it implemented > - how is the patch series structured > - make the reference counting unconditional > - special case static (never released) policies > - replace standard ref counting by per-cpu reference counting - introduce pidfd_set_mempolicy > - how has this been tested? -- Michal Hocko SUSE Labs
