On Fri, Mar 24, 2023 at 9:31 PM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > On Fri, Mar 24, 2023 at 7:18 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > [...] > > Any ideas here are welcome! > > > > Let's move forward. It seems like we are not going to reach an > agreement on making cgroup_rstat_lock a non-irq lock. However there is > agreement on the memcg code of not flushing in irq context and the > cleanup Johannes has requested. Let's proceed with those for now. We > can come back to cgroup_rstat_lock later if we still see issues in > production. Even if we do not flush from irq context, we still flush from atomic contexts that will currently hold the lock with irqs disabled throughout the entire flush sequence. A primary purpose of this reason is to avoid that. We can either: (a) Proceed with the following approach of making cgroup_rstat_lock a non-irq lock. (b) Proceed with Tejun's suggestion of always releasing and reacquiring the lock at CPU boundaries, even for atomic flushes (if the spinlock needs a break ofc). (c) Something else. I am happy to proceed with any solution, but we need to address the fact that interrupts are always disabled throughout the flush. My main concern about Tejun's suggestion is atomic contexts having to contend cgroup_rstat_lock much more than they do now, but it's still better than what we have today. > > Tejun, do you have any concerns on adding WARN_ON_ONCE(!in_task()) in > the rstat flushing code?
