On Sat, Jul 25, 2020 at 5:52 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > On Fri, Jul 24, 2020 at 09:36:03PM +0200, Bartosz Golaszewski wrote: > > On Mon, Jul 20, 2020 at 10:14 AM Maxim Kochetkov <fido_max@xxxxxxxx> wrote: > > > > > > It works fine with this patch. Thank you so much! > > > > > > 18.07.2020 07:25, Kent Gibson пишет: > > > > On Fri, Jul 17, 2020 at 06:07:04PM +0300, Andy Shevchenko wrote: > > > >> On Fri, Jul 17, 2020 at 5:17 PM Maxim Kochetkov <fido_max@xxxxxxxx> wrote: > > > >>> > > > >>> I need a small userspace program to do some GPIO magic to communicate > > > >>> other hardware like devmem. This program takes about 2,5 seconds just to > > > >>> find GPIO lines by name. > > > >>> > > > >>> replacing synchronize_rcu to synchronize_rcu_expedited in > > > >>> atomic_notifier_chain_unregister gives the same boost as removing > > > >>> synchronize_rcu > > > >> > > > >> Have you tried to replace an atomic notifier call with a regular one? > > > >> IIRC it's still not clear why atomic is used there. > > > >> > > > > > > > > Indeed, I recently submitted a patch to switch the > > > > atomic_notifier_call_chain to blocking_notifier_call_chain, as some of > > > > the chained calls can sleep. > > > > Not sure if that is related, or if the change would make this case better > > > > or worse, but it would be interesting to find out. > > > > The patch is in the current gpio/devel, btw. > > > > > > > > Cheers, > > > > Kent. > > > > > > > > Linus, > > > > I think we should consider submitting this patch for stable then > > because this slow-down was affects previously existing use-cases. > > > > That patch is post the cdev split, so it certainly wont apply to an > older kernel. I'm happy to backport it if you need it - just > nominate the branch you want it for. Let's let this land upstream in the merge window and then we can consider backports for performance regressions. Yours, Linus Walleij