At 03/21/2018 05:34 PM, Dou Liyang wrote:
Hi Peter,
At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
How about:
possible_cpus= [s390,x86_64] Set the number of possible CPUs which
are determined by the ACPI tables MADT or
is invalid, we should prevent it from being
accounted >
This fixes a bug that Purley platform displays too many possible cpu
Signed-off-by: Li RongQing
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Dou Liyang
---
arch/x86/include/asm/apic.h | 4 ++--
arch/x86/kernel/acpi/
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
RongQing,
At 04/09/2018 02:38 PM, Li,Rongqing wrote:
-邮件原件-
发件人: Dou Liyang [mailto:douly.f...@cn.fujitsu.com]
发送时间: 2018年4月9日 13:38
收件人: Li,Rongqing ; linux-kernel@vger.kernel.org;
t...@linutronix.de; mi...@redhat.com; h...@zytor.com; jgr...@suse.com;
x...@kernel.org; pet
if id is larger than
0x7fff, this is wrong
and if local_apic_id is invalid, we should prevent it from being
accounted
This fixes a bug that Purley platform displays too many possible cpu
Signed-off-by: Li RongQing
Suggested-by:: Dou Liyang
Hi Maintainers,
I have a question about "__ref" in Linux kernel.
When I looked into the __irq_alloc_descs(), I found it tagged a
"__ref" mark, but I didn't find that it referenced code or data
from init section.
So, I confuse why the "__ref" is needed in __irq_alloc_descs()?
any other reasons?
Hi All,
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote:
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote:
Then looks this issue need to fix by making possible CPU count
accurate
because there are other resources allocated according to
Hi Rafael,
Thank you so much for your reply.
At 03/13/2018 05:25 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 4:11 AM, Dou Liyang wrote:
Hi Thomas,
At 03/09/2018 11:08 PM, Thomas Gleixner wrote:
[...]
I'm not sure if there is a clear indicator whether physcial hotpl
Hi Artem,
At 03/14/2018 11:29 AM, Dou Liyang wrote:
Hi All,
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy
wrote:
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote:
Then looks this issue need to fix by making possible CPU count
accurate
Hi Artern,
At 03/14/2018 05:07 PM, Artem Bityutskiy wrote:
On Wed, 2018-03-14 at 12:11 +0800, Dou Liyang wrote:
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy
Longer term, yeah, I agree. Kernel's notion of possible CPU
count
shou
possible CPU count from the number of Local APIC
entries in ACPI MADT. It doesn't consider with the ACPI namespace and
reports unrealistically high numbers.
Depth-first search the namespace tree, check and collect the correct CPUs
and update the possible map
Signed-off-by: Dou Liyang
---
dr
which allows to expand this in the future without touching all the
functions ever again, just modify the data irq_affinity_desc structure.
Reported-by: Kashyap Desai
Reported-by: Sumit Saxena
Suggested-by: Thomas Gleixner
Signed-off-by: Dou Liyang
---
Changelog:
v2 --> v3
- Crea
Hi Bjorn,
on 2018/11/29 4:00, Bjorn Helgaas wrote:
[+cc linux-pci]
Since you mention reports, are there URLs to mailing list archives you
can include?
OK, I will add it:
https://marc.info/?l=linux-kernel&m=153543887027997&w=2
- entry = alloc_msi_entry(&dev->dev, nvec, masks);
+ e
Hi Thomas,
On 2018/11/29 6:03, Thomas Gleixner wrote:
+ affi_desc = kcalloc(nvec, sizeof(*affi_desc), GFP_KERNEL);
Why do you want to do that separate allocation here? Just let
I thought the irq_create_affinity_desc() also can be called by other
functions which may convert cp
In case of irq_default_affinity != cpu_possible_mask, setting the affinity
for the pre/post vectors to irq_default_affinity is a breakage.
Just set the pre/post vectors to cpu_possible_mask and be done with it.
Suggested-by: Thomas Gleixner
Signed-off-by: Dou Liyang
---
kernel/irq/affinity.c
y should be mapped as unmanaged
interrupts. So, only transfering the irq affinity assignments is not enough.
Add a new bit "is_managed" to convey the info in irq_affinity_desc and use
it in alloc_descs().
Reported-by: Kashyap Desai
Reported-by: Sumit Saxena
Signed-off-by: Dou Liyang
spreading managed
flags.
Suggested-by: Thomas Gleixner
Suggested-by: Bjorn Helgaas
Signed-off-by: Dou Liyang
---
drivers/pci/msi.c | 9 -
include/linux/interrupt.h | 14 --
include/linux/irq.h | 6 --
include/linux/irqdomain.h | 6 --
include/linux/msi.h
is_managed : 1; |
| }; |
| |
+--+
[1]:https://marc.info/?l=linux-kernel&m=153543887027997&w=2
Dou Liyang (3):
genirq/affinity: Add a new interrupt affinity descriptor
irq/
can't both seting the affinity mask and the managed flag.
So, decouple the managed flag from the affinity mask, add a new bitmap to
differentiate between managed and unmanaged interrupts.
Reported-by: Kashyap Desai
Reported-by: Sumit Saxena
Suggested-by: Thomas Gleixner
Signed-off
Hi Rafael,
At 05/28/2018 04:40 PM, Rafael J. Wysocki wrote:
Can you please resend the patch with the above information in the
changelog of it?
Yes, I resend the patch right now.
That would make it easier to review and discuss it.
Also I think that we need some sort of a check against dup
failedsuccess
the others processor(ID=89)
hot-add failed failed
So, Remove the check code.
Signed-off-by: Dou Liyang
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 126 -
The vector_alloc tracepont reversed the reserved and ret aggs, that made
the trace print wrong. Exchange them.
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/trace/irq_vectors.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/trace/irq_vectors.h
b
case:
Before the patch, After the patch
the first processor(ID=89)
hot-addfailedsuccess
the others processor(ID=89)
hot-add failedfailed
So, What's your idea about
f the duplicate processor, the others can be ignored).
So, Remove the check code.
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 126 --
include/linux/acpi.h | 3 -
2 files changed, 129 deletions(-)
diff --git a/drivers
Hi tglx,
on 2018/12/5 16:28, Thomas Gleixner wrote:
On Tue, 4 Dec 2018, Dou Liyang wrote:
In case of irq_default_affinity != cpu_possible_mask, setting the affinity
for the pre/post vectors to irq_default_affinity is a breakage.
Why so? All interrupts which are not managed get te default
Dear Thomas,
On 2018/9/17 23:32, Thomas Gleixner wrote:
[...]
I think it's still worthwhile to do that, but the changelog needs a major
overhaul as right now it's outright misleading. I'll just amend it with
something along the above lines, unless someone disagrees.
Yeah, Yes, right, I was wr
At 07/13/2018 07:30 PM, Pavel Tatashin wrote:
On Fri, Jul 13, 2018 at 3:24 AM Dou Liyang wrote:
At 07/12/2018 08:04 AM, Pavel Tatashin wrote:
During boot tsc is calibrated twice: once in tsc_early_delay_calibrate(),
and the second time in tsc_init().
Rename tsc_early_delay_calibrate
At 07/16/2018 09:35 PM, Pavel Tatashin wrote:
[...]
v13 has xen patches, so xen timestamps work early as well now.
Oops, yes, my mistake. I will test the patchset with Thomas's kvm patch
for you.
Thanks,
dou
Thank you,
Pavel
At 05/22/2018 09:47 AM, Dou Liyang wrote:
At 05/19/2018 11:06 PM, Thomas Gleixner wrote:
On Tue, 20 Mar 2018, Dou Liyang wrote:
ACPI driver should make sure all the processor IDs in their ACPI
Namespace
are unique for CPU hotplug. the driver performs a depth-first walk of
the
namespace
set at the first step.
Simplify the second step, make it just work for APIC=y.
Signed-off-by: Dou Liyang
---
arch/x86/kernel/idt.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
index 2c3a1b4294eb..74383a3780dc 100644
--- a
*/
early_per_cpu(x86_cpu_to_logical_apicid, cpu) =
logical_smp_processor_id();
Thanks,
dou
arch/x86/kernel/apic/apic.c:1507:2: note: each undeclared identifier is
reported only once for each function it appears in
vim +/i +1507 arch/x86/kernel/apic/apic.c
2066f4d6 arch/x86/kernel/a
This is a tiny cleanup patchset for setup_local_APIC().
Dou Liyang (3):
x86/apic: Move pending intr check code into it's own function
x86/apic: Replace common tools with new ones
x86/apic: Drop the logical_smp_processor_id()
arch/x86/include/asm/smp.h | 10 -
arch/x86/kernel
The pending interrupt check code is old, update the following.
-Replace for-if pair with for_each_set_bit()
-Replace printk() with pr_err()
Also merge the printk's code in one line and make curly braces balanced
Suggested-by: Andy Shevchenko
Signed-off-by: Dou Liyang
Reviewed-by:
The logical_smp_processor_id() which is only called in setup_local_APIC()
on x86_32 system looks redundant.
Drop it, then directly use GET_APIC_LOGICAL_ID() marco and more suitable
variable name for readability
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/smp.h | 10 --
arch/x86
the pending interrupt check code is mixed with the local APIC setup code,
that looks messy.
Extract the related code, move it into a new function named
apic_pending_intr_clear().
Signed-off-by: Dou Liyang
Reviewed-by: Andy Shevchenko
---
changelog:
v4 --> v5:
- Fix undeclared '
the early_trap_init() and cpu_set_gdt() have been abandoned, so remove
them.
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/processor.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index b0ccd4847a58..3ef3221107c3
Hi Ingo, Kees, Baoquan and Chao
At 03/12/2018 06:57 PM, Ingo Molnar wrote:
[...]
So there's apparently a mis-design here:
- KASLR needs to be done very early on during bootup: - it's not realistic to
expect KASLR to be done with a booted up kernel, because pointers to various
KASLR-ed
Hi Jan,
At 04/27/2018 03:21 PM, Jan Beulich wrote:
Hello,
I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent CPUs, the firmware may not know the APIC IDs
The MADT table is
At 04/27/2018 08:09 PM, Jan Beulich wrote:
On 27.04.18 at 10:32, wrote:
At 04/27/2018 03:21 PM, Jan Beulich wrote:
I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent CPUs
Hi Jan,
At 05/02/2018 02:39 PM, Jan Beulich wrote:
On 02.05.18 at 03:56, wrote:
At 04/27/2018 08:09 PM, Jan Beulich wrote:
I'm afraid I don't understand: Limiting the number of disabled CPUs is
certainly desirable when those can never be used, but why would you
want to do this when they might
Hi Thomas,
Sorry to ask the questions at this series, my mailbox was kicked out of
the mailing list a few days ago, and didn't receive the e-mail.
please see below
At 05/29/2018 04:09 AM, Thomas Gleixner wrote:
On Mon, 28 May 2018, Song Liu wrote:
This doesn't fix the issue with bnxt. Here is
Hi Thomas,
At 06/04/2018 07:17 PM, Thomas Gleixner wrote:
On Mon, 4 Jun 2018, Dou Liyang wrote:
Here, why didn't we avoid this cleanup by
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index a75de0792942..0cc59646755f 100644
--- a/arch/x86/kernel/apic/vec
Hi Thomas,
At 06/04/2018 11:33 PM, Thomas Gleixner wrote:
The generic pending interrupt mechanism moves interrupts from the interrupt
handler on the original target CPU to the new destination CPU. This is
required for x86 and ia64 due to the way the interrupt delivery and
acknowledge works if th
Hi Thomas,
At 06/04/2018 11:33 PM, Thomas Gleixner wrote:
apic_ack_edge() is explicitely for handling interrupt affinity cleanup when
interrupt remapping is not available or disable.
Remapped interrupts and also some of the platform specific special
interrupts, e.g. UV, invoke ack_APIC_irq() di
Hi Thomas,
At 06/05/2018 07:41 PM, Thomas Gleixner wrote:
On Tue, 5 Jun 2018, Dou Liyang wrote:
+{
+ if (unlikely(irqd_is_setaffinity_pending(irqd)))
Affinity pending is also judged in
+ irq_move_irq(irqd);
If we can remove the if(...) statement here
That requires
Hi Thomas,
At 06/06/2018 04:04 PM, Thomas Gleixner wrote:
On Wed, 6 Jun 2018, Dou Liyang wrote:
Hi Thomas,
At 06/05/2018 07:41 PM, Thomas Gleixner wrote:
On Tue, 5 Jun 2018, Dou Liyang wrote:
+{
+ if (unlikely(irqd_is_setaffinity_pending(irqd)))
Affinity pending is also judged in
Now, Linux uses matrix allocator for vector assignment, the original
assignment code which used VECTOR_OFFSET_START has been removed.
So remove the stale macro as well
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/irq_vectors.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch
mplex.
Remove the code of the X86_LOCAL_APIC=n case to simplify it.
Signed-off-by: Dou Liyang
---
arch/x86/kernel/idt.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c
index 2c3a1b4294eb..8b4174890706 100644
--- a/arc
The macro FPU_IRQ has never been used since v3.10, So remove it.
Signed-off-by: Dou Liyang
---
arch/x86/include/asm/irq_vectors.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/irq_vectors.h
b/arch/x86/include/asm/irq_vectors.h
index 57003074bd7a..548d90bbf919 100644
From: Dou Liyang
As Kashyap and Sumit reported, in MSI/-x subsystem, the pre/post vectors
may be used to some extra reply queues for performance. the best way to
map the pre/post vectors is map them to the local numa node.
But, current Linux can't do that, because
The pre and post ve
At 08/10/2018 10:35 AM, Dou Liyang wrote:
When compiling kernel with SMP disabled, the build warns with:
kernel/sched/core.c: In function ‘update_rq_clock_task’:
kernel/sched/core.c:139:17: warning: unused variable ‘irq_delta’
[-Wunused-variable]
s64 steal = 0, irq_delta = 0;
Fix this
From: Dou Liyang
Linux has spread out the non managed interrupt across the possible
target CPUs to avoid vector space exhaustion.
But, the same situation may happen on the managed interrupts.
Spread managed interrupt on allocation as well.
Fixes: a0c9259dc4e1("irq/matrix: Spread interrup
From: Dou Liyang
Linux finds the CPU which has the lowest vector allocation count to spread
out the non managed interrupt across the possible target CPUs.
This common CPU finding code will also be used in managed case,
So Split it out into a helper for preparation.
Signed-off-by: Dou Liyang
Hi Kashyap,
On 2018/9/20 16:39, Kashyap Desai worte:
Dou - Do you want me to test your patch or shall I wait for next version
?
I'm sorry, please wait for the next version.
Thanks,
dou
From: Dou Liyang
Linux finds the CPU which has the lowest vector allocation count to spread
out the non managed interrupt across the possible target CPUs.
This common CPU finding code will also be used in managed case,
So Split it out into a helper for preparation.
Signed-off-by: Dou Liyang
From: Dou Liyang
Linux has spread out the non managed interrupt across the possible
target CPUs to avoid vector space exhaustion.
But, the same situation may happen on the managed interrupts.
Spread managed interrupt on allocation as well.
Fixes: a0c9259dc4e1("irq/matrix: Spread interrup
From: Dou Liyang
Linux has spread out the non managed interrupt across the possible
target CPUs to avoid vector space exhaustion.
But, the same situation may happen on the managed interrupts.
Spread managed interrupt on allocation as well.
Note: also change the return value for the empty
From: Dou Liyang
Linux finds the CPU which has the lowest vector allocation count to spread
out the non managed interrupt across the possible target CPUs.
This common CPU finding code will also be used in managed case,
So Split it out into a helper for preparation.
Signed-off-by: Dou Liyang
At 05/19/2018 11:06 PM, Thomas Gleixner wrote:
On Tue, 20 Mar 2018, Dou Liyang wrote:
ACPI driver should make sure all the processor IDs in their ACPI Namespace
are unique for CPU hotplug. the driver performs a depth-first walk of the
namespace tree and calls the acpi_processor_ids_walk
Hi Thomas,
At 05/19/2018 08:32 PM, Thomas Gleixner wrote:
On Thu, 26 Apr 2018, Dou Liyang wrote:
The vectors between FIRST_SYSTEM_VECTOR and NR_VECTORS are special IRQ
vectors used by the SMP architecture. But, if X86_LOCAL_APIC=n, it will
not be used, and the FIRST_SYSTEM_VECTOR is equal to
t kernel
to be randomized in the home node by adding a parameter. this parameter sets
up the boundaries between the home nodes and other nodes.
Reported-by: Chao Fan
Signed-off-by: Dou Liyang
Reviewed-by: Kees Cook
---
Changelog:
-Rewrite the commit log and document.
Documentation/admin-gu
ux/commits/Dou-Liyang/ACPI-processor-Get-accurate-possible-CPU-count/20180316-140349
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
caused below changes (please refer to attached dmesg/kmsg for entire
log
x27;s
pointless.
Merge the two function to avoid this situation and make the code simplify.
Signed-off-by: Dou Liyang
---
arch/x86/kernel/apic/vector.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vec
Hi Andy,
At 03/15/2018 01:24 AM, Andy Shevchenko wrote:
On Wed, Mar 14, 2018 at 12:28 PM, Dou Liyang wrote:
+static void __init acpi_update_possible_map(void)
+{
+ unsigned int cpu, nr = 0;
+
+ if (nr_cpu_ids <= nr_unique_ids)
+ ret
Depth-first search the namespace tree, check and collect the correct CPUs
and update the possible map.
Signed-off-by: Dou Liyang
---
Changelog v1 --> v2:
-Optimize the code by Andy Shevchenko's suggestion
-modify the changelog
drivers/acpi/acpi_processor.c | 21 +
1
Hi Thomas,
At 03/15/2018 09:45 PM, Thomas Gleixner wrote:
[...]
I tested this on a machine which claims to have gazillion of hotplugable
CPUs:
I really appreciate your test.
smpboot: Allowing 152 CPUs, 120 hotplug CPUs
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_id
Hi Stephen,
At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used
[-Wunused-function]
static bool cpuhp_is_ap_state(e
Hi Stephen,
At 03/16/2018 01:52 PM, Dou Liyang wrote:
Hi Stephen,
At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64
allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state'
by: Stephen Rothwell
Signed-off-by: Dou Liyang
---
kernel/cpu.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index a1860d42aacf..db7ec7572348 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -126,15 +126,6 @@ struct cpuhp_step {
At 03/16/2018 03:59 PM, Thomas Gleixner wrote:
On Fri, 16 Mar 2018, Dou Liyang wrote:
Commit 17a2f1ced028 ("cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states")
removed the last use of cpuhp_is_atomic_state() in common case, that caused
Kernel produced a warning:
'cp
t physical NUMA Node hotplug, and
we can't get memory hotplug info from ACPI SRAT earlier now(If we can do
that, we even can remove the 'movable_node' option).
So, IMO, extend movable_node to replace the misuse of 'mem' option.
Thought?
Thanks,
dou
At 04/
s/ID/IDs/
s/inr_logical_cpuidi/nr_logical_cpuids/
s/generic_processor_info()/__generic_processor_info()/
Signed-off-by: Dou Liyang
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
Hi, Ingo
At 01/05/2017 04:15 PM, Ingo Molnar wrote:
* Dou Liyang wrote:
s/inr_logical_cpuidi/nr_logical_cpuids/
s/generic_processor_info()/__generic_processor_info()/
Signed-off-by: Dou Liyang
---
arch/x86/kernel/apic/apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
s step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
arch/ia64/kernel/ac
<-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-
27;
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished s
both of them as being unreasonable;
The function will record the unique or duplicate processor IDs.
The duplicate processor IDs such as 89 are regarded as the unreasonable IDS
which mean that the processor objects in question are not valid.
Signed-off-by: D
control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40
hen cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
arch/x86/mm/numa.c | 27 +--
1 file changed, 13 insertions(+), 14 deletio
establish all possible cpuid <-> nodeid mapping, we will use the
proc_id from ACPI table.
We do validation when we get the proc_id. If the result is true, we will
stop the mapping.
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 16
drivers/acpi/proce
emory-less nodes so that memory allocator will fall
back to proper nodes automatically.
Change log v1 -> v2:
1. Split code movement and actual changes. Add patch 1.
2. Synchronize best near online node record when node hotplug happens. In patch
2.
3. Fix some comment.
Dou Liyang (2)
27;
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished s
control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40
<-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-
.
When we establish all possible cpuid <-> nodeid mapping to handle the
cpu hotplugs, we will use the proc_id from ACPI table.
We do validation when we get the proc_id. If the result is true, we
will stop the mapping.
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 16 ++
mark both of them as being unreasonable;
The function will record the unique or duplicate processor IDs.
The duplicate processor IDs such as 89 are regarded as the unreasonable IDs
which mean that the processor objects in question are not valid.
Signed-off-by: Dou Liyang
---
drivers
s step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
arch/ia64/kernel/ac
before per cpu areas were initialized.
Change log v2 -> v3:
1. Online memory-less nodes at boot time to map cpus of memory-less nodes.
2. Build zonelists for memory-less nodes so that memory allocator will fall
back to proper nodes automatically.
Change log v1 -> v2:
1. Split code movem
As a result, when cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
arch/x86/mm/numa.c | 27 +--
1 file changed, 13 insert
在 2016年07月26日 07:20, Andrew Morton 写道:
On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang wrote:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/o
g v2 -> v3:
1. Online memory-less nodes at boot time to map cpus of memory-less nodes.
2. Build zonelists for memory-less nodes so that memory allocator will fall
back to proper nodes automatically.
Change log v1 -> v2:
1. Split code movement and actual changes. Add patch 1.
2. Synchr
<-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-
As a result, when cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
arch/x86/mm/numa.c | 27 +--
1 file changed, 13 insert
.
When we establish all possible cpuid <-> nodeid mapping to handle the
cpu hotplugs, we will use the proc_id from ACPI table.
We do validation when we get the proc_id. If the result is true, we
will stop the mapping.
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 16 ++
mark both of them as being unreasonable;
The function will record the unique or duplicate processor IDs.
The duplicate processor IDs such as 89 are regarded as the unreasonable IDs
which mean that the processor objects in question are not valid.
Signed-off-by: Dou Liyang
---
drivers
control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40
s step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
Signed-off-by: Dou Liyang
---
arch/ia64/kernel/ac
27;
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished s
Hi, RJ
在 2016年07月26日 19:53, Rafael J. Wysocki 写道:
On Tuesday, July 26, 2016 11:59:38 AM Dou Liyang wrote:
在 2016年07月26日 07:20, Andrew Morton 写道:
On Mon, 25 Jul 2016 16:35:42 +0800 Dou Liyang wrote:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And wor
Hi Yinghai,
At 10/06/2016 12:53 PM, Yinghai Lu wrote:
On Wed, Oct 5, 2016 at 7:04 AM, Thomas Gleixner wrote:
@@ -176,6 +177,11 @@ static int acpi_register_lapic(int id, u
return -EINVAL;
}
+if (!enabled && (id == disabled_id)) {
+++disabled_cpus;
+return -EIN
101 - 200 of 577 matches
Mail list logo
