David Rientjes wrote:
On Tue, 10 Nov 2009, Ingo Molnar wrote:
I'm waiting for Mike to test them (and other patches) and send a new
series out with bits to pick up.
Mike posted his series today without including my patch, so I've replied
to it.
Sorry, I wasn't aware I should have.
But i really dont like such type of buffering - in the past they tended
to be problematic.
I'm not sure that I'd call it buffering when iterating through all apic
id's and setting appropriate bits in a bitmap when they map to a node id.
It's apparently not been problematic either on my machines, Mike's
machines, or his merge with ACPI 4.0 code. I think the code is pretty
straight forward.
Why print this info at all in the default bootup?
It's not needed on a correctly functioning system.
We have no other export of the apic id to to node mappings in the kernel.
We already show each pxm's address range, each node's address range, and
the pxm to node map. The only other way to map apic ids to nodes is by
looking for the lines "CPU 0/0 -> Node 0," which I believe are being
removed.
The bootup messages in my patch 1/7 list nodes and their processors as each
boots. And this is easily found under /sysfs.
Also, I think in general that all the apic messages, unless they represent
"system boot progress" should be displayed only when asked for, like with
apic=debug or verbose? Something more like:
BIOS-provided physical RAM map processed.
EFI: memory allocated.
SRAT: table interpreted.
Bootmem setups complete.
ACPI: APIC's enabled.
PM: Registered all nosave memory.
Removing the above tables remove about 3400 lines of console output on a 1k
thread machine. There are 20,000+ lines of output before you get to the
login prompt (even with the removal of cpu bootup messages).
But you are right, the apic info should be available via /sysfs or /procfs.
The next BIG output is from devices. Listing all the pci busses available
is an overkill as that info is also readily available when the system is
running.
--
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
