All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Jander <david@protonic.nl>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
	Kent Gibson <warthog618@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: regression: gpiolib: switch the line state notifier to atomic unexpected impact on performance
Date: Tue, 11 Mar 2025 13:30:10 +0100	[thread overview]
Message-ID: <20250311133010.760abd61@erd003.prtnl> (raw)
In-Reply-To: <CAMRc=MewC-7XFfWxPS7cmMycxo-62NDrUKFyjnnCbwqXQXWuZw@mail.gmail.com>

On Tue, 11 Mar 2025 12:45:51 +0100
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> On Tue, Mar 11, 2025 at 11:01 AM David Jander <david@protonic.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).

I had libgpiod version 1.6.3 and I have now built libgpiod version 2.1.3.

Here are my findings:

1. time gpiodetect on kernel 6.13 and gpiod 1.6.3:

$ time gpiodetect 
gpiochip0 [GPIOA] (16 lines)
gpiochip1 [GPIOB] (16 lines)
gpiochip10 [GPIOK] (8 lines)
gpiochip11 [GPIOZ] (8 lines)
gpiochip12 [unknown] (22 lines)
gpiochip13 [mcp23s17.0] (16 lines)
gpiochip14 [0-0020] (16 lines)
gpiochip15 [0-0021] (16 lines)
gpiochip2 [GPIOC] (16 lines)
gpiochip3 [GPIOD] (16 lines)
gpiochip4 [GPIOE] (16 lines)
gpiochip5 [GPIOF] (16 lines)
gpiochip6 [GPIOG] (16 lines)
gpiochip7 [GPIOH] (16 lines)
gpiochip8 [GPIOI] (16 lines)
gpiochip9 [GPIOJ] (16 lines)
real    0m 0.19s
user    0m 0.00s
sys     0m 0.01s

2. time gpiodetect on kernel 6.13 and gpiod 2.1.3:

$ time gpiodetect 
gpiochip0 [GPIOA] (16 lines)
gpiochip1 [GPIOB] (16 lines)
gpiochip2 [GPIOC] (16 lines)
gpiochip3 [GPIOD] (16 lines)
gpiochip4 [GPIOE] (16 lines)
gpiochip5 [GPIOF] (16 lines)
gpiochip6 [GPIOG] (16 lines)
gpiochip7 [GPIOH] (16 lines)
gpiochip8 [GPIOI] (16 lines)
gpiochip9 [GPIOJ] (16 lines)
gpiochip10 [GPIOK] (8 lines)
gpiochip11 [GPIOZ] (8 lines)
gpiochip12 [unknown] (22 lines)
gpiochip13 [mcp23s17.0] (16 lines)
gpiochip14 [0-0020] (16 lines)
gpiochip15 [0-0021] (16 lines)
real    0m 0.22s
user    0m 0.00s
sys     0m 0.06s

(note that it became slightly slower from v1 -> v2)

3. time gpiodetect on kernel 6.12 and gpiod 1.6.3:

$ time gpiodetect 
gpiochip0 [GPIOA] (16 lines)
gpiochip1 [GPIOB] (16 lines)
gpiochip10 [GPIOK] (8 lines)
gpiochip11 [GPIOZ] (8 lines)
gpiochip12 [unknown] (22 lines)
gpiochip13 [mcp23s17.0] (16 lines)
gpiochip14 [0-0020] (16 lines)
gpiochip15 [0-0021] (16 lines)
gpiochip2 [GPIOC] (16 lines)
gpiochip3 [GPIOD] (16 lines)
gpiochip4 [GPIOE] (16 lines)
gpiochip5 [GPIOF] (16 lines)
gpiochip6 [GPIOG] (16 lines)
gpiochip7 [GPIOH] (16 lines)
gpiochip8 [GPIOI] (16 lines)
gpiochip9 [GPIOJ] (16 lines)
real    0m 0.03s
user    0m 0.00s
sys     0m 0.01s

4. time gpiodetect on kernel 6.12 and gpiod 2.1.3:

$ time gpiodetect 
gpiochip0 [GPIOA] (16 lines)
gpiochip1 [GPIOB] (16 lines)
gpiochip2 [GPIOC] (16 lines)
gpiochip3 [GPIOD] (16 lines)
gpiochip4 [GPIOE] (16 lines)
gpiochip5 [GPIOF] (16 lines)
gpiochip6 [GPIOG] (16 lines)
gpiochip7 [GPIOH] (16 lines)
gpiochip8 [GPIOI] (16 lines)
gpiochip9 [GPIOJ] (16 lines)
gpiochip10 [GPIOK] (8 lines)
gpiochip11 [GPIOZ] (8 lines)
gpiochip12 [unknown] (22 lines)
gpiochip13 [mcp23s17.0] (16 lines)
gpiochip14 [0-0020] (16 lines)
gpiochip15 [0-0021] (16 lines)
real    0m 0.07s
user    0m 0.00s
sys     0m 0.06s

(roughly same speed difference from v1 -> v2).

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?

Best regards,

-- 
David Jander

  reply	other threads:[~2025-03-11 12:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-11 10:00 regression: gpiolib: switch the line state notifier to atomic unexpected impact on performance David Jander
2025-03-11 10:21 ` Bartosz Golaszewski
2025-03-11 11:03   ` David Jander
2025-03-12  1:32     ` Kent Gibson
2025-03-12  8:08       ` David Jander
2025-03-12  9:10         ` Kent Gibson
2025-03-12 10:24           ` David Jander
2025-03-12 12:10             ` Kent Gibson
2025-03-11 11:45 ` Bartosz Golaszewski
2025-03-11 12:30   ` David Jander [this message]
2025-03-11 13:21     ` Bartosz Golaszewski
2025-03-11 14:09       ` David Jander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250311133010.760abd61@erd003.prtnl \
    --to=david@protonic.nl \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=warthog618@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.