linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-pci@vger.kernel.org
Subject: Re: PCI service interrupt handlers & access to PCI config space
Date: Tue, 13 Apr 2021 11:35:56 +0200	[thread overview]
Message-ID: <20210413093556.g24nzwhgmpgvqoxt@pali> (raw)
In-Reply-To: <20210410162622.GA23381@wunner.de>

On Saturday 10 April 2021 18:26:22 Lukas Wunner wrote:
> On Sat, Apr 10, 2021 at 05:17:09PM +0200, Pali Rohár wrote:
> > On Saturday 10 April 2021 16:25:24 Lukas Wunner wrote:
> > > raw_spin_locks are not supposed to be held for a prolonged
> > > period of time.
> > 
> > What is "prolonged period of time"? Because for example PCIe controller
> > on A3720 has upper limit about 1.5s when accessing config space. This is
> > what I measured in real example. It really took PCIe HW more than 1s to
> > return error code if it happens.
> 
> Linux Device Drivers (2005) says:
> 
>    "The last important rule for spinlock usage is that spinlocks must
>     always be held for the minimum time possible. The longer you hold
>     a lock, the longer another processor may have to spin waiting for
>     you to release it, and the chance of it having to spin at all is
>     greater. Long lock hold times also keep the current processor from
>     scheduling, meaning that a higher priority process -- which really
>     should be able to get the CPU -- may have to wait. The kernel
>     developers put a great deal of effort into reducing kernel latency
>     (the time a process may have to wait to be scheduled) in the 2.5
>     development series. A poorly written driver can wipe out all that
>     progress just by holding a lock for too long. To avoid creating
>     this sort of problem, make a point of keeping your lock-hold times
>     short."
> 
> 1.5 sec is definitely too long.  This sounds like a quirk of this
> specific hardware.  Try to find out if the hardware can be configured
> differently to respond quicker.

I have not found any option how to configure it to respond quicker.
Upper limit for controller hw in error condition (e.g. when card does
not respond) seems to be always 1.5 sec.

      parent reply	other threads:[~2021-04-13  9:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-10 12:28 PCI service interrupt handlers & access to PCI config space Pali Rohár
2021-04-10 14:25 ` Lukas Wunner
2021-04-10 15:17   ` Pali Rohár
2021-04-10 16:26     ` Lukas Wunner
2021-04-12  2:25       ` Keith Busch
2021-04-12 14:04         ` Pali Rohár
2021-04-12 15:09           ` Keith Busch
2021-04-13  9:33             ` Pali Rohár
2021-04-13  9:35       ` Pali Rohár [this message]

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=20210413093556.g24nzwhgmpgvqoxt@pali \
    --to=pali@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).