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

From: Mike Travis
Date: Wed Oct 28 2009 - 13:02:29 EST




Andi Kleen wrote:
MAX_LOCAL_APIC was definitely an arbitrary choice here and has very little relevance. scnlistprintf will protect against overflow, but we still need to decide upon a constant that will emit the most information possible while not overly polluting the printk and saving on bss, as you mentioned. I suspect we could agree on a value as little as 128 and it would work for the overwhelming majority (all?) of users.

For now at least seems reasonable to limit to 128 or so yes (and go
back to the stack). if we ever have sparse apic ids for nodes then that might change; but in this case could still just do
a acpidump or teach the printer to be more clever and support
strides.

It would be just good to have some indication in the output
if there was a overflow.

-Andi


I don't understand the importance of this when the memory is given back
after the system starts up anyway...?

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/