All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Bjorn Helgaas <helgaas@kernel.org>, Paul Menzel <pmenzel@molgen.mpg.de>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: `pci_apply_final_quirks()` taking half a second
Date: Sat, 08 Apr 2017 19:00:19 +0200	[thread overview]
Message-ID: <1491670819.6021.33.camel@infradead.org> (raw)
In-Reply-To: <20170408154128.GA16832@bhelgaas-glaptop.roam.corp.google.com>

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Sat, 2017-04-08 at 10:41 -0500, Bjorn Helgaas wrote:
> 
> > Measuring where time is spent during boot with `systemd-bootchart`
> > on an Asus A780FullHD, it turns out that half a second is spent in
> > `pci_apply_final_quirks()`.
> 
> I agree, that seems like a crazy amount of time.
> 
> Can you figure out how to turn on pr_debug() (via the dynamic debug
> mess or whatever) and boot with "initcall_debug"?  That should tell us
> how long each quirk took.

It could well be spending a fair amount of time just attempting to
match each device against the list. When I first implemented the table-
based quirks, back in the mists of time, there were relatively few. 

Now I wonder if it's worth sorting the list by vendor ID or something,
at least for the common case of the quirks which match on
vendor/device.

I note it's also reading PCI_CACHE_LINE_SIZE From config space for each
device in pci_apply_final_quirks(). How long does that take?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]

  reply	other threads:[~2017-04-08 17:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 21:07 `pci_apply_final_quirks()` taking half a second Paul Menzel
2017-04-08 15:41 ` Bjorn Helgaas
2017-04-08 17:00   ` David Woodhouse [this message]
2017-04-08 19:06     ` Bjorn Helgaas
2017-05-03 18:42       ` Andy Shevchenko
2017-12-26 15:55   ` Paul Menzel
2017-12-28 21:27     ` Bjorn Helgaas
2017-12-28 21:27       ` Bjorn Helgaas
2017-12-29 16:14       ` Alan Stern
2017-12-29 16:14         ` Alan Stern
2017-12-29 16:14         ` Alan Stern
2017-12-31  7:18         ` Paul Menzel
2017-12-31  7:18           ` Paul Menzel
2017-12-31 21:16           ` Alan Stern
2017-12-31 21:16             ` Alan Stern
2017-12-31 21:16             ` Alan Stern
2018-01-01 10:21             ` Paul Menzel
2018-01-01 10:21               ` Paul Menzel
2018-01-01 15:47               ` Alan Stern
2018-01-01 15:47                 ` Alan Stern
2018-01-01 15:47                 ` Alan Stern
2018-06-24 16:49             ` `quirk_usb_handoff_ohci` takes over 73 ms (twice) on AMD system (was: `pci_apply_final_quirks()` taking half a second) Paul Menzel
2018-06-24 16:49               ` `pci_apply_final_quirks()` taking half a second Paul Menzel

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=1491670819.6021.33.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.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 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.