Hi Peter,
At 04/06/2018 05:05 PM, Peter Zijlstra wrote:
On Fri, Apr 06, 2018 at 11:02:28AM +0200, Peter Zijlstra wrote:
On Fri, Apr 06, 2018 at 04:42:14PM +0800, Dou Liyang wrote:
Hi Thomas, Peter,
At 04/03/2018 07:23 PM, Peter Zijlstra wrote:
On Tue, Apr 03, 2018 at 12:25:56PM +0200, Thomas Gleixner wrote:
On Mon, 2 Apr 2018, Li RongQing wrote:
lots of application will read /proc/stat, like ps and vmstat, but we
find the reading time are spreading on Purley platform which has lots
of possible CPUs and interrupt.
To reduce the reading time, only scan the present CPUs, not all possible
CPUs, which speeds the reading of /proc/stat 20 times on Purley platform
which has 56 present CPUs, and 224 possible CPUs
Why is BIOS/ACPI telling the kernel that there are 224 possible CPUs unless
it supports physical CPU hotplug.
BIOS is crap, news at 11. I've got boxes like that too. Use
possible_cpu=$nr if you're bothered by it -- it's what I do.
Yes, I think so. it is a manual way to reset the number.
For this situation, I am investigating to restrict the number of
possible CPUs automatically, But, due to the limitation of ACPI
subsystem, I can do it _before_ setup_percpu_area where the number will
be used.
Ah, did you mean to day "I can _NOT_ do it" ? Still I don't see the
^----------- Oops, yes.
point of frobbing random users if the whole thing is buggered.
If ACPI subsystem can be initialized earlier, we can get the accurate
number of possible CPUs from the ACPI namespace. then, we can reset the
_cpu_possible_mask_ as the prefill_possible_map() does. So, it can
forbid random users.
But, It needs the memory to be initialized first, so it can't be called
earlier setup_percpu_area() which is evoked earlier than mem_init().
and you are right:
"So if you see it enumerates a gazillion empty spots but the system does
not in fact support physical hotplug, we should discard those."
I will think it more carefully.
Thanks,
dou
