On Tue 29-08-23 13:20:34, Yosry Ahmed wrote: [...] > I will add a mutex on the userspace read side then and spin a v3. > Hopefully this addresses Michal's concern as well. The lock dropping > logic will still exist for the inner lock, but when one userspace > reader drops the inner lock other readers won't be able to pick it up. Yes, that would minimize the risk of the worst case pathological behavior. > > I don't have a strong preference. As long as we stay away from introducing a > > new user interface construct and can address the noticed scalability issues, > > it should be fine. Note that there are other ways to address priority > > inversions and contentions too - e.g. we can always bounce flushing to a > > [kthread_]kworker and rate limit (or rather latency limit) how often > > different classes of users can trigger flushing. I don't think we have to go > > there yet but if the simpler meaures don't work out, there are still many > > ways to solve the problem within the kernel. > > I whole-heartedly agree with the preference to fix the problem within > the kernel with minimal/none user space involvement. Let's see. While I would love to see a solution that works for everybody without explicit interface we have hit problems with locks involved in stat files in the past. -- Michal Hocko SUSE Labs
