Re: [PATCH] genirq: only scan the present CPUs
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
Re: [PATCH] genirq: only scan the present CPUs
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
Re: [PATCH] genirq: only scan the present CPUs
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.
Re: [PATCH] genirq: only scan the present CPUs
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.
Re: [PATCH] genirq: only scan the present CPUs
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.
Re: [PATCH] genirq: only scan the present CPUs
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.
Re: [PATCH] genirq: only scan the present CPUs
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
Re: [PATCH] genirq: only scan the present CPUs
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
Re: [PATCH] genirq: only scan the present CPUs
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.
Re: [PATCH] genirq: only scan the present CPUs
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.
Re: [PATCH] genirq: only scan the present CPUs
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
Re: [PATCH] genirq: only scan the present CPUs
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
