On Thu, Jul 18, 2024 at 11:23 PM Waiman Long <longman@xxxxxxxxxx> wrote: > > > On 7/18/24 17:49, David Finkel wrote: > > I spent some time today attempting to implement this. > > Here's a branch on github that compiles, and I think is close to what you > > described, but is definitely still a WIP: > > > > https://github.com/torvalds/linux/compare/master...dfinkel:linux:memcg2_memory_peak_fd_session > > > > Since there seems to be significant agreement that this approach is better > > long-term as a kernel interface, if that continues, I can factor out some of > > the changes so it supports both memory.peak and memory.swap.peak, > > fix the tests, and clean up any style issues tomorrow. > > > > Also, If there are opinions on whether the cgroup_lock is a reasonable way > > of handling this synchronization, or if I should add a more appropriate spinlock > > or mutex onto either the pagecounter or the memcg, I'm all ears. > > cgroup_lock() should only be used by the cgroup core code, though there > are exceptions. > > You may or may not need lock protection depending on what data you want > to protect and if there is any chance that concurrent race may screw > thing up. If lock protection is really needed, add your own lock to > protect the data. Since your critical sections seem to be pretty short, > a regular spinlock will be enough. Thanks, using cgroup_lock() created a deadlock, and using a spinlock resolved that. > > Cheers, > Longman > -- David Finkel Senior Principal Software Engineer, Core Services
