On Mon, Oct 02, 2023 at 07:51:10AM +0530, Neeraj upadhyay wrote: > On Mon, Oct 2, 2023 at 4:10 AM Frederic Weisbecker <frederic@xxxxxxxxxx> wrote: > > And if this works, can we then remove srcu_invoke_callbacks() self-requeue? > > If queued several times before it actually fires, it will catch the latest > > grace period's end. And if queued while the callback runs, it will re-run. > > > > This makes sense, but not sure for non-wq context which link [1] mentions, > whether it needs it. I don't see a problem with it, see below. > > > Also why do we have sdp->srcu_invoke_callbacks ? Is that workqueue re-entrant? > > > I think you mean sdp->srcu_cblist_invoking ? Right! > > There was a prior discussion on this [1], where Paul mentions about > non-wq context. I don't see that function called elsewhere than workqueue. So in early boot, works queued must wait for workqueue_init() (and kthreads creation and running) which is quite late in the boot process. So it looks like SRCU isn't really usable synchonously in early boot. Besides, this workqueue is already re-entrant. Several srcu_invoke_callbacks() calls can already execute concurrently, which is fine thanks to the snp locking. So I don't see an obvious need for this re-entrancy protection (coming along the requeue thing). Thanks. > > > > Thanks > Neeraj > > [1] https://lkml.org/lkml/2020/11/19/1065 > > > Thanks.
