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
Signed-off-by: Li RongQing <[email protected]>
---
kernel/irq/irqdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 49b54e9979cc..8f489b73733e 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -902,7 +902,7 @@ unsigned int kstat_irqs(unsigned int irq)
if (!desc || !desc->kstat_irqs)
return 0;
- for_each_possible_cpu(cpu)
+ for_each_present_cpu(cpu)
sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
return sum;
}
--
2.11.0
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.
Thanks,
tglx
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.
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.
But, I can provider an indicator to tell the system that whether the
physical CPU hotplug is support or not later. Can we use this indicator
like that in this situation:
if ture
Using for_each_possible_cpu(cpu)
else
Using for_each_present_cpu(cpu)
Thanks,
dou
>
>
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.
>
> But, I can provider an indicator to tell the system that whether the
> physical CPU hotplug is support or not later. Can we use this indicator
> like that in this situation:
If anything you should fix up the enumeration; not random users after
the fact.
So if you see it enumerates a gazillion empty spots but the system does
not in fact support physical hotplug, we should discard those.
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
point of frobbing random users if the whole thing is buggered.
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
>
>