From: David Matlack <dmatlack@google.com>
To: Michal Clapinski <mclapinski@google.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Lukas Wunner <lukas@wunner.de>,
linux-kernel@vger.kernel.org,
Pasha Tatashin <pasha.tatashin@soleen.com>
Subject: Re: [PATCH RESEND] PCI/DOE: Poll briefly for a response before sleeping
Date: Fri, 16 Oct 2026 20:17:18 +0000 [thread overview]
Message-ID: <atKGTn7PqaDaednD@google.com> (raw)
In-Reply-To: <20261012114213.1757207-1-mclapinski@google.com>
On 2026-10-12 01:42 PM, Michal Clapinski wrote:
> doe_statemachine_work() waits for a response by sleeping
> PCI_DOE_POLL_INTERVAL (PCI_DOE_TIMEOUT / 128) between status reads,
> which is 7 ms at HZ=1000 and 4 ms at HZ=250. Exchanges are served from
> the device's local mailbox logic and typically complete within tens of
> microseconds, so nearly all of that sleep is wasted. Every DOE-capable
> endpoint pays it once per supported feature during enumeration.
>
> Poll with usleep_range(20, 50) for the first ~2 ms before falling back
> to the jiffies-based wait. On an Intel Emerald Rapids system, time spent
> in pci_device_add() for a DOE-capable endpoint drops from 41.8 ms to
> 14.0 ms.
Does any of this remaining time come from pci_doe_abort()? I see that is
also called during mailbox creation and has the same call to
pci_doe_wait(). If so, maybe the poll logic can be shared.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>
> ---
> I was asked if I can do this with interrupts instead. I don't see a way
> to do that during device enumeration that won't collide with the
> drivers.
> ---
> drivers/pci/doe.c | 28 +++++++++++++++++++++++-----
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
> index 6b5d9ba8e969..5e93d78a1a97 100644
> --- a/drivers/pci/doe.c
> +++ b/drivers/pci/doe.c
> @@ -27,6 +27,9 @@
> /* Timeout of 1 second from 6.30.2 Operation, PCI Spec r6.0 */
> #define PCI_DOE_TIMEOUT HZ
> #define PCI_DOE_POLL_INTERVAL (PCI_DOE_TIMEOUT / 128)
It would be nice to also fix the HZ=100 issue, in a separate patch
within the same series, since you are updating this code.
> +#define PCI_DOE_POLL_FAST_MIN_US 20
> +#define PCI_DOE_POLL_FAST_MAX_US 50
> +#define PCI_DOE_POLL_FAST_TRIES 40
>
> #define PCI_DOE_FLAG_CANCEL 0
> #define PCI_DOE_FLAG_DEAD 1
> @@ -487,7 +490,7 @@ static void doe_statemachine_work(struct work_struct *work)
> int offset = doe_mb->cap_offset;
> unsigned long timeout_jiffies;
> u32 val;
> - int rc;
> + int rc, tries = 0;
>
> if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags)) {
> signal_task_complete(task, -EIO);
> @@ -525,10 +528,25 @@ static void doe_statemachine_work(struct work_struct *work)
> signal_task_abort(task, -EIO);
> return;
> }
> - rc = pci_doe_wait(doe_mb, PCI_DOE_POLL_INTERVAL);
> - if (rc) {
> - signal_task_abort(task, rc);
> - return;
> + /*
> + * Exchanges are served from the device's local mailbox
> + * logic and usually complete in tens of microseconds, far
> + * below the jiffies granularity of PCI_DOE_POLL_INTERVAL.
> + * Poll for up to ~2 ms before falling back to it.
> + */
If tens of microsecond is the norm then is polling for up to 2ms
overkill?
> + if (tries++ < PCI_DOE_POLL_FAST_TRIES) {
> + if (test_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags)) {
> + signal_task_abort(task, -EIO);
> + return;
> + }
> + usleep_range(PCI_DOE_POLL_FAST_MIN_US,
> + PCI_DOE_POLL_FAST_MAX_US);
> + } else {
> + rc = pci_doe_wait(doe_mb, PCI_DOE_POLL_INTERVAL);
> + if (rc) {
> + signal_task_abort(task, rc);
> + return;
> + }
> }
> goto retry_resp;
> }
> --
> 2.56.0.385.gd3acb90ef8-goog
>
next prev parent reply other threads:[~2026-10-16 20:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 11:42 [PATCH RESEND] PCI/DOE: Poll briefly for a response before sleeping Michal Clapinski
2026-10-12 11:51 ` sashiko-bot
2026-10-12 11:53 ` Michał Cłapiński
2026-10-16 20:17 ` David Matlack [this message]
2026-10-16 20:45 ` Michał Cłapiński
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=atKGTn7PqaDaednD@google.com \
--to=dmatlack@google.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mclapinski@google.com \
--cc=pasha.tatashin@soleen.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.