On Thu, Mar 09, 2023 at 01:57:42PM +0100, Uladzislau Rezki wrote: [..] > > > > > > See this commit: > > > > > > > > > > > > 3705b88db0d7cc ("rcu: Add a module parameter to force use of > > > > > > expedited RCU primitives") > > > > > > > > > > > > Antti provided this commit precisely in order to allow Android > > > > > > devices to expedite the boot process and to shut off the > > > > > > expediting at a time of Android userspace's choosing. So Android > > > > > > has been making this work for about ten years, which strikes me > > > > > > as an adequate proof of concept. ;-) > > > > > > > > > > Thanks for the pointer. That's true. Looking at Android sources, I > > > > > find that Android Mediatek devices at least are setting > > > > > rcu_expedited to 1 at late stage of their userspace boot (which is > > > > > weird, it should be set to 1 as early as possible), and > > > > > interestingly I cannot find them resetting it back to 0!. Maybe > > > > > they set rcu_normal to 1? But I cannot find that either. Vlad? :P > > > > > > > > Interesting. Though this is consistent with Antti's commit log, > > > > where he talks about expediting grace periods but not unexpediting > > > > them. > > > > > > > Do you think we need to unexpedite it? :)))) > > > > Android runs on smallish systems, so quite possibly not! > > > We keep it enabled and never unexpedite it. The reason is a performance. I > have done some app-launch time analysis with enabling and disabling of it. > > An expedited case is much better when it comes to app launch time. It > requires ~25% less time to run an app comparing with unexpedited variant. > So we have a big gain here. Wow, that's huge. I wonder if you can dig deeper and find out why that is so as the callbacks may need to be synchronize_rcu_expedited() then, as it could be slowing down other usecases! I find it hard to believe, real-time workloads will run better without those callbacks being always-expedited if it actually gives back 25% in performance! thanks, - Joel