On Thu, Nov 03, 2022 at 01:44:51PM +0100, Uladzislau Rezki wrote: > > > > > Though I am thinking, workqueue context is normally used to invoke > > > code that can block, and would the issue you mentioned affect those as > > > well, or affect RCU when those non-RCU work items block. So for > > > example, when other things in the system that can queue things on the > > > system_wq and block. (I might be throwing darts in the dark). > > > > > > To be safe, we can implement your suggestion which is basically a form > > > of my initial patch. > > > > > > Should we add Tejun to the thread? > > > > Let's get organized first, but that would be a good thing. Or I could > > reach out to Tejun internally. > > > > For but one thing to get organized about, maybe kfree_rcu() should be > > using a workqueue with the WQ_MEM_RECLAIM flag set. > > > It can be as an option to consider. Because such workqueue has some > special priority for better handling of memory releasing. I can have > a look at it closer to see how kvfree_rcu() works if it goes with WQ_MEM_RECLAIM. > An extra note. It would work well with posted patch because we can directly queue the reclaim work to the WQ_MEM_RECLAIM queue. As for now RCU-core kthreads like: rcugp, rcuop use "regular" queue. I think system_wq one. -- Uladzislau Rezki
