Re: [patch] x86: reduce srat verbosity in the kernel log

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





David Rientjes wrote:
On Wed, 28 Oct 2009, Mike Travis wrote:

I'm not saying it would be illegal, merely that it would be harm
readability.  Based on how apic id's are formed from processor ids, though,
I think we're really talking about an upper limit (128) that will never be
reached.
We actually have many, many more than that by adding on some extra bits
to the CPU's apicid.  These select which blade in the system to target.


Maybe I've been vague in my rationale for why this limit will probably never be reached. The way apic ids are constructed, with physical and logical processor ids, it tends to lend itself to ranges where bitmap_scnlistprintf() can specify a large number of apic ids with relatively few ASCII characters because logical processors typically do not have differing pxms. For us to reach the 128 character upper bound, scnlistprintf() would need to have many, many distinct ranges; your example showed two ranges per pxm (many more machines would have only a single range). In other words, we're not predicting to have "1-2,4-6,8-9,11-13,15-17," etc, that we often have with nodemasks.

Yes, you are correct.  (I was confused... ;-)

I believe the disjointed ranges came from the hyperthread cpus..?  Which if
true means there'll probably be as many distinct ranges as there are threads
per core?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux