On Thu, Jul 13, 2023 at 11:17 PM Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> wrote: > > > > On 2023/7/14 10:16, Paul E. McKenney wrote: > > On Thu, Jul 13, 2023 at 09:33:35AM -0700, Paul E. McKenney wrote: > >> On Thu, Jul 13, 2023 at 11:33:24AM -0400, Joel Fernandes wrote: > > ... > > >>> > >>> >From what Sandeep described, the code path is in an RCU reader. My > >>> question is more, why doesn't it use SRCU instead since it clearly > >>> does so if BLK_MQ_F_BLOCKING. What are the tradeoffs? IMHO, a deeper > >>> dive needs to be made into that before concluding that the fix is to > >>> use rcu_read_lock_any_held(). > >> > >> How can this be solved? > >> > >> 1. Always use a workqueue. Simple, but is said to have performance > >> issues. > >> > >> 2. Pass a flag in that indicates whether or not the caller is in an > >> RCU read-side critical section. Conceptually simple, but might > >> or might not be reasonable to actually implement in the code as > >> it exists now. (You tell me!) > >> > >> 3. Create a function in z_erofs that gives you a decent > >> approximation, maybe something like the following. > >> > >> 4. Other ideas here. > > > > 5. #3 plus make the corresponding Kconfig option select > > PREEMPT_COUNT, assuming that any users needing compression in > > non-preemptible kernels are OK with PREEMPT_COUNT being set. > > (Some users of non-preemptible kernels object strenuously > > to the added overhead from CONFIG_PREEMPT_COUNT=y.) > > I'm not sure if it's a good idea I think it is a fine idea. > we need to work on > CONFIG_PREEMPT_COUNT=n (why not?), we could just always trigger a > workqueue for this. > So CONFIG_PREEMPT_COUNT=n users don't deserve good performance? ;-) thanks, - Joel
