Re: gpiolib gpio_chrdev_release duration is about 30 ms

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

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