[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=McLEtiF4tfGpOGW+agA8-BK_qU6UWjvq1BOgthWXXym3A@mail.gmail.com>
Date: Tue, 11 Mar 2025 14:21:37 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: David Jander <david@...tonic.nl>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Kent Gibson <warthog618@...il.com>,
Linus Walleij <linus.walleij@...aro.org>, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: regression: gpiolib: switch the line state notifier to atomic
unexpected impact on performance
On Tue, Mar 11, 2025 at 1:30 PM David Jander <david@...tonic.nl> wrote:
>
> On Tue, 11 Mar 2025 12:45:51 +0100
> Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> > On Tue, Mar 11, 2025 at 11:01 AM David Jander <david@...tonic.nl> wrote:
> > >
> > > On kernel 6.13, after git revert -n fcc8b637c542 time is back to what it was
> > > on 6.12.
> > >
> >
> > Interestingly: I cannot reproduce it. Obviously gpiofind doesn't exist
> > in libgpiod v2 but I'm running gpiodetect with and without reverting
> > these changes and am getting roughly the same results: ~0.050s real
> > time for 1 up to 4 chips.
> >
> > Any idea why that could be? Can you reproduce it with libgpiod v2 (I
> > don't know why that wouldn't be the case but worth double checking).
>
>
> Can you describe your platform? Is it a multi-core or single-core CPU? What
> RCU implementation does it use? Tree or tiny? If it is multi-core, is there a
> difference if you disable all but one core?
> Maybe some kernel CONFIG option that makes a difference? I am not an expert in
> RCU (in fact I barely know what it does), so maybe I am missing something that
> makes this problem go away?
>
I'm testing on a qemu VM - SMP and single core. RCU algo is tree. In
any case: I've just sent you an RFT patch that switches to using the
raw notifier. Could you see what results you're getting with it?
Bart
Powered by blists - more mailing lists