lkml.org 
[lkml]   [2012]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] revert "PCI: log vendor/device ID always"
On 10/05/2012 10:16 AM, Bjorn Helgaas wrote:
> On Fri, Oct 5, 2012 at 8:54 AM, Nathan Zimmer <nzimmer@sgi.com> wrote:
>> On 10/05/2012 09:14 AM, Joe Perches wrote:
>>> On Fri, 2012-10-05 at 08:55 -0500, Nathan Zimmer wrote:
>>>> On 10/04/2012 11:37 AM, Joe Perches wrote:
>>>>> On Thu, 2012-10-04 at 11:02 -0500, Nathan Zimmer wrote:
>>>>>> At many of our customer sites the log level is set to KERN_DEBUG. It
>>>>>> helps avoid reboots due to operator impatience. Machines this large
>>>>>> take significantly longer then typical to boot and seeing the extra
>>>>>> messages reassures them that the kernel isn't hung.
>>>>> That argues for adding some KERN_INFO "still booting" messages
>>>>> not logging unnecessary KERN_DEBUG messages.
>>>>>
>>>> Actually I would think that argues for reducing boot times on these
>>>> large systems.
>>> Right.
>>>
>>> That's an independent argument, but sure, go ahead
>>> and do that too.
>>>
>>
>> Here is output for my workstation a simple 4x box
>>
>> -bash-4.1$ dmesg | grep "type [0-9][0-9] class" | wc
>> 12 108 804
>> -bash-4.1$ dmesg | wc
>> 744 6359 49474
>>
>>
>> Here is some output from one of the biggest boxes.
>>
>> -bash-4.1$ dmesg | wc
>> 26503 235414 1811651
>> -bash-4.1$ dmesg | grep "type [0-9][0-9] class" | wc
>> 12085 108765 821780
> Many vendors don't expose host bridges that lead to the CPU-related
> PCI devices because they don't want the OS to muck with them. We
> currently blindly probe for these in domain 0, so we find them anyway
> (I think we should change this behavior).
>
> I'd guess that having all these CPU-related devices around also really
> clutters up "lspci" output, and of course, consumes memory for all the
> pci_dev structs in the kernel. It takes some time to enumerate them
> all, so avoiding that would speed up boot somewhat.

Yea now that you mention it lspci is quite cluttered.

>
> So I wonder if it might be more useful to figure out how to avoid
> enumerating those devices in the first place? The first step would be
> to stop exposing PNP0A03/PNP0A08 host bridges that lead to them. As I
> mentioned, we currently will probably find them anyway via blind
> probing. You might be able to avoid that if you could place them in a
> PCI domain other than 0.
>
> Bjorn

This seems like a better way to go. I'll start digging down this route.


\
 
 \ /
  Last update: 2012-10-05 18:21    [W:0.079 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site