[tip:irq/core] genirq/affinity: Add is_managed to struct irq_affinity_desc

Commit-ID: c410abbbacb9b378365ba17a30df08b4b9eec64f Gitweb: https://git.kernel.org/tip/c410abbbacb9b378365ba17a30df08b4b9eec64f Author: Dou Liyang AuthorDate: Tue, 4 Dec 2018 23:51:21 +0800 Committer: Thomas Gleixner CommitDate: Wed, 19 Dec 2018 11:32:08 +0100 genirq/affinity: Add

[tip:irq/core] genirq/core: Introduce struct irq_affinity_desc

Commit-ID: bec04037e4e484f41ee4d9409e40616874169d20 Gitweb: https://git.kernel.org/tip/bec04037e4e484f41ee4d9409e40616874169d20 Author: Dou Liyang AuthorDate: Tue, 4 Dec 2018 23:51:20 +0800 Committer: Thomas Gleixner CommitDate: Wed, 19 Dec 2018 11:32:08 +0100 genirq/core: Introduce

Re: [PATCH 3/3] irq/affinity: Fix a possible breakage

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

[PATCH 2/3] irq/affinity: Add is_managed into struct irq_affinity_desc

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

[PATCH 3/3] irq/affinity: Fix a possible breakage

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

[PATCH 1/3] genirq/core: Add a new interrupt affinity descriptor

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

[PATCH 0/3] irq/core: Fix and expand the irq affinity descriptor

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/

Re: [RFC PATCH v3] genirq/affinity: Create and transfer more irq desc info by a new structure

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

Re: [RFC PATCH v3] genirq/affinity: Create and transfer more irq desc info by a new structure

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

[RFC PATCH v3] genirq/affinity: Create and transfer more irq desc info by a new structure

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

[RFC PATCH v2] gen/irq: Change the way to differentiate between managed and unmanaged interrupts by bitmap

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

Re: [RFC PATCH] irq/affinity: Mark the pre/post vectors as regular interrupts

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

[tip:x86/apic] irq/matrix: Spread managed interrupts on allocation

Commit-ID: 76f99ae5b54d48430d1f0c5512a84da0ff9761e0 Gitweb: https://git.kernel.org/tip/76f99ae5b54d48430d1f0c5512a84da0ff9761e0 Author: Dou Liyang AuthorDate: Sun, 9 Sep 2018 01:58:38 +0800 Committer: Thomas Gleixner CommitDate: Tue, 18 Sep 2018 18:27:24 +0200 irq/matrix: Spread

[tip:x86/apic] irq/matrix: Split out the CPU selection code into a helper

Commit-ID: 8ffe4e61c06a48324cfd97f1199bb9838acce2f2 Gitweb: https://git.kernel.org/tip/8ffe4e61c06a48324cfd97f1199bb9838acce2f2 Author: Dou Liyang AuthorDate: Sun, 9 Sep 2018 01:58:37 +0800 Committer: Thomas Gleixner CommitDate: Tue, 18 Sep 2018 18:27:24 +0200 irq/matrix: Split out

Re: [PATCH v3 2/2] irq/matrix: Spread managed interrupts on allocation

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

Re: [PATCH] sched/core: Fix compiling warring in smp=n case

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

[RFC PATCH] irq/affinity: Mark the pre/post vectors as regular interrupts

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

[PATCH v3 2/2] irq/matrix: Spread managed interrupts on allocation

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

[PATCH v3 1/2] irq/matrix: Split out the CPU finding code into a helper

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

[PATCH v2 2/2] irq/matrix: Spread managed interrupts on allocation

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

[PATCH v2 1/2] irq/matrix: Split out the CPU finding code into a helper

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

[PATCH 2/2] irq/matrix: Spread managed interrupts on allocation

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

[PATCH 1/2] irq/matrix: Split out the CPU finding code into a helper

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

[PATCH v3] acpi/processor: Fix the return value of acpi_processor_ids_walk()

erator for processor enumeration") Signed-off-by: Dou Liyang --- Changelog: v2 --> v3: - Fix a compiler error reported by LKP v1 --> v2: - Fix the check against duplicate IDs suggested by Rafael. Now，the duplicate IDs only be found in Ivb42 machine, and we have added this

[RESEND PATCH v2] acpi/processor: Fix the return value of acpi_processor_ids_walk()

erator for processor enumeration") Signed-off-by: Dou Liyang --- Changelog: v1 --> v2: - Fix the check against duplicate IDs suggested by Rafael. Now，the duplicate IDs only be found in Ivb42 machine, and we have added this check at linux-4.9. But, we introduced a bug in li

[PATCH] sched/core: Fix compiling warring in smp=n case

(CONFIG_IRQ_TIME_ACCOUNTING) || defined(CONFIG_PARAVIRT_TIME_ACCOUNTING) Fixes: 2e62c4743adc ("sched/fair: Remove #ifdefs from scale_rt_capacity()") Signed-off-by: Dou Liyang --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.

Re: [PATCH v4 2/4] x86/boot: Add acpitb.c to parse acpi tables

At 07/23/2018 05:29 PM, Chao Fan wrote: Imitate the ACPI code to parse ACPI tables. Functions are simplified cause some operations are not needed here. And also, this method won't influence the initialization of ACPI. Signed-off-by: Chao Fan Hi Fan, I know you got the code from acpica sub

Re: [PATCH v4 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

At 08/02/2018 03:05 PM, Thomas Gleixner wrote: [...] Folks. Can you please both stop this annoying habit of keeping the full context of the mail and then sprinkling a random sentence into the middle? I see. won’t do this stupid thing again. Thanks, dou

Re: [PATCH v4 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

At 08/02/2018 02:00 PM, Chao Fan wrote: On Thu, Aug 02, 2018 at 01:46:29PM +0800, Dou Liyang wrote: Hi Fan, At 07/23/2018 05:29 PM, Chao Fan wrote: If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable memory regions is not zero. Calculate the intersection betw

Re: [PATCH v4 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

Hi Fan, At 07/23/2018 05:29 PM, Chao Fan wrote: If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable memory regions is not zero. Calculate the intersection between memory regions from e820/efi memory table and immovable memory regions. Or go on the old code. Rename process_mem_re

Re: [PATCH v4 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

Hi Fan, At 07/23/2018 05:29 PM, Chao Fan wrote: If 'CONFIG_MEMORY_HOTREMOVE' specified, walk the acpi srat memory tables, store the immovable memory regions, so that kaslr can get the information abouth where can be selected or not. If 'CONFIG_MEMORY_HOTREMOVE' not specified, go on the old code.

[tip:x86/platform] x86/platform/UV: Mark memblock related init code and data correctly

Commit-ID: 24cfd8ca1d28331b9dad3b88d1958c976b2cfab6 Gitweb: https://git.kernel.org/tip/24cfd8ca1d28331b9dad3b88d1958c976b2cfab6 Author: Dou Liyang AuthorDate: Mon, 30 Jul 2018 15:59:47 +0800 Committer: Thomas Gleixner CommitDate: Mon, 30 Jul 2018 19:53:58 +0200 x86/platform/UV: Mark

[tip:x86/timers] x86/tsc: Consolidate init code

Commit-ID: 608008a45798fe9e2aee04f99b5270ea57c1376f Gitweb: https://git.kernel.org/tip/608008a45798fe9e2aee04f99b5270ea57c1376f Author: Dou Liyang AuthorDate: Mon, 30 Jul 2018 15:54:20 +0800 Committer: Thomas Gleixner CommitDate: Mon, 30 Jul 2018 19:33:35 +0200 x86/tsc: Consolidate

[tip:x86/timers] x86/kvmclock: Mark kvm_get_preset_lpj() as __init

Commit-ID: 1088c6eef261939bda8346ec35b513790a2111d5 Gitweb: https://git.kernel.org/tip/1088c6eef261939bda8346ec35b513790a2111d5 Author: Dou Liyang AuthorDate: Mon, 30 Jul 2018 15:54:21 +0800 Committer: Thomas Gleixner CommitDate: Mon, 30 Jul 2018 19:33:35 +0200 x86/kvmclock: Mark

Re: [PATCH 1/2] x86/tsc: Avoid a double call if TSC initializes earlier.

Hi Peter, At 07/30/2018 05:34 PM, Peter Zijlstra wrote: On Mon, Jul 30, 2018 at 03:54:20PM +0800, Dou Liyang wrote: static_branch_enable(&__use_tsc) may be called twice in common case, that is redundant. It is also really not a problem... Yes, right. Just avoid the second useless set

[PATCH] x86/apic: Mark parse_mem_block_size as __init

The early_param() is only called during kernel initialization, So Linux marks the functions of it with __init macro to save memory. But it forgot to mark parse_mem_block_size(). So, Make it __init as well. Aslo mark mem_block_size variable __initdata. Signed-off-by: Dou Liyang --- arch/x86

[PATCH 1/2] x86/tsc: Avoid a double call if TSC initializes earlier.

init/tsc_init Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: Pavel Tatashin Signed-off-by: Dou Liyang --- arch/x86/kernel/tsc.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/tsc.c b/a

[PATCH 2/2] x86/kvmclock: Mark kvm_get_preset_lpj() as __init

kvm_get_preset_lpj() just be called at kvmclock_init(), So mark it __init as well. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: k...@vger.kernel.org Signed-off-by: Dou Liyang --- arch/x86/kernel/kvmclock.c | 2 +

[PATCH 0/2] Two cleanup patches

Here are two cleanup patches, When I test the early boot time stamps with tip tree today. Dou Liyang (2): x86/tsc: Avoid a double call if tsc can initialize earlier. x86/kvmclock: Mark kvm_get_preset_lpj() as __init arch/x86/kernel/kvmclock.c | 2 +- arch/x86/kernel/tsc.c | 22

Re: [PATCH v14 20/25] x86/tsc: calibrate tsc only once

Hi Thomas, At 07/19/2018 02:25 PM, Thomas Gleixner wrote: On Thu, 19 Jul 2018, Dou Liyang wrote: At 07/18/2018 10:22 AM, Pavel Tatashin wrote: + (unsigned long)cpu_khz % KHZ); if (cpu_khz != tsc_khz) { pr_info("Detected %lu.%03lu MH

Re: [PATCH v14 20/25] x86/tsc: calibrate tsc only once

Hi, Pavel I am sorry, I didn't point out typo clearly in the previous version. Please see the concerns below. ;-) At 07/18/2018 10:22 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_ca

Re: [PATCH v13 13/18] x86/tsc: calibrate tsc only once

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

Re: [PATCH v13 13/18] x86/tsc: calibrate tsc only once

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

Re: [PATCH v13 14/18] x86/tsc: initialize cyc2ns when tsc freq. is determined

At 07/12/2018 08:04 AM, Pavel Tatashin wrote: cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data structure. Currently, the setup code for c2ns data for every possible CPU goes through the same sequence of calculations as for the boot CPU, but is based on the same tsc freq

Re: [PATCH v13 13/18] x86/tsc: calibrate tsc only once

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() to tsc_early_init(), and rework it so the calibration is done only early, and make tsc_init() to use the

Re: Bug report about KASLR and ZONE_MOVABLE

Hi Baoquan, At 07/11/2018 08:40 PM, Baoquan He wrote: Please try this v3 patch: >>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Wed, 11 Jul 2018 20:31:51 +0800 Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text In find_zone_m

[tip:x86/urgent] x86/vector: Fix the args of vector_alloc tracepoint

Commit-ID: 838d76d63ec4eaeaa12bedfa50f261480f615200 Gitweb: https://git.kernel.org/tip/838d76d63ec4eaeaa12bedfa50f261480f615200 Author: Dou Liyang AuthorDate: Fri, 1 Jun 2018 14:50:31 +0800 Committer: Thomas Gleixner CommitDate: Wed, 6 Jun 2018 13:38:02 +0200 x86/vector: Fix the args

[tip:x86/urgent] x86/idt: Simplify the idt_setup_apic_and_irq_gates()

Commit-ID: 336628128826a9acb045571a960e32e4414ccb61 Gitweb: https://git.kernel.org/tip/336628128826a9acb045571a960e32e4414ccb61 Author: Dou Liyang AuthorDate: Wed, 23 May 2018 10:35:55 +0800 Committer: Thomas Gleixner CommitDate: Wed, 6 Jun 2018 13:38:01 +0200 x86/idt: Simplify the

Re: [patch 3/8] x86/apic: Provide apic_ack_irq()

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

Re: [patch 3/8] x86/apic: Provide apic_ack_irq()

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

Re: [patch 3/8] x86/apic: Provide apic_ack_irq()

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

Re: [patch 2/8] genirq/generic_pending: Do not lose pending affinity update

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

Re: WARNING and PANIC in irq_matrix_free

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

Re: WARNING and PANIC in irq_matrix_free

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

[PATCH] x86/vector: Fix the args of vector_alloc tracepoint

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

[RESEND RFC PATCH] acpi/processor: Remove the check of duplicate processors

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 -

Re: [PATCH 0/1] Remove the check of duplicate processors

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

[PATCH v2] x86/idt: Simplify the idt_setup_apic_and_irq_gates()

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

Re: [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()

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

Re: [PATCH] x86/idt: Simplify the idt_setup_apic_and_irq_gates()

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

Re: [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()

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

[tip:x86/apic] x86/vector: Merge allocate_vector() into assign_vector_locked()

Commit-ID: 2773397171ac4b6e794ba0b3e34c06cbaf29897a Gitweb: https://git.kernel.org/tip/2773397171ac4b6e794ba0b3e34c06cbaf29897a Author: Dou Liyang AuthorDate: Fri, 11 May 2018 16:09:56 +0800 Committer: Thomas Gleixner CommitDate: Sat, 19 May 2018 15:09:11 +0200 x86/vector: Merge

[RFC PATCH 1/1] acpi/processor: Remove the check of duplicate processors

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

[PATCH 0/1] Remove the check of duplicate processors

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

[PATCH] x86/vector: Merge the allocate_vector() into assign_vector_locked()

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

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

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

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

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

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

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

[tip:x86/urgent] x86/vector: Remove the unused macro FPU_IRQ

Commit-ID: 7d878817db22f64c2b2c241335ec03e4c3fd5476 Gitweb: https://git.kernel.org/tip/7d878817db22f64c2b2c241335ec03e4c3fd5476 Author: Dou Liyang AuthorDate: Thu, 26 Apr 2018 14:08:32 +0800 Committer: Thomas Gleixner CommitDate: Thu, 26 Apr 2018 11:57:57 +0200 x86/vector: Remove the

[PATCH] x86/vector: Remove the unused macro FPU_IRQ

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

[PATCH] x86/idt: Simplify the idt_setup_apic_and_irq_gates()

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

[tip:x86/urgent] x86/vector: Remove the macro VECTOR_OFFSET_START

Commit-ID: e3072805c61167b85a30ceeef606620704db31f7 Gitweb: https://git.kernel.org/tip/e3072805c61167b85a30ceeef606620704db31f7 Author: Dou Liyang AuthorDate: Wed, 25 Apr 2018 10:05:53 +0800 Committer: Ingo Molnar CommitDate: Thu, 26 Apr 2018 07:31:17 +0200 x86/vector: Remove the

[tip:x86/urgent] x86/vector: Remove the macro VECTOR_OFFSET_START

Commit-ID: 5a626a8dfb58a64a39f4351e3962e7320191f189 Gitweb: https://git.kernel.org/tip/5a626a8dfb58a64a39f4351e3962e7320191f189 Author: Dou Liyang AuthorDate: Wed, 25 Apr 2018 10:05:53 +0800 Committer: Thomas Gleixner CommitDate: Wed, 25 Apr 2018 10:56:24 +0200 x86/vector: Remove the

[PATCH] x86/vector: Remove the macro VECTOR_OFFSET_START

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

Re: [RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

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/

[tip:x86/urgent] x86/processor: Remove two unused function declarations

Commit-ID: 451cf3ca7d4615631443014ee769c25e267c25ff Gitweb: https://git.kernel.org/tip/451cf3ca7d4615631443014ee769c25e267c25ff Author: Dou Liyang AuthorDate: Wed, 4 Apr 2018 14:45:27 +0800 Committer: Thomas Gleixner CommitDate: Tue, 17 Apr 2018 11:56:32 +0200 x86/processor: Remove

[tip:x86/urgent] x86/acpi: Prevent X2APIC id 0xffffffff from being accounted

Commit-ID: 10daf10ab154e31237a8c07242be3063fb6a9bf4 Gitweb: https://git.kernel.org/tip/10daf10ab154e31237a8c07242be3063fb6a9bf4 Author: Dou Liyang AuthorDate: Thu, 12 Apr 2018 09:40:52 +0800 Committer: Thomas Gleixner CommitDate: Tue, 17 Apr 2018 11:56:31 +0200 x86/acpi: Prevent

[PATCH] x86/acpi: Prevent X2APIC id 0xffffffff from being accounted

chitecture x2APIC Specification", Chapter 2.4.1. Add a sanity check to acpi_parse_x2apic() which ignores the invalid id. Reported-by: Li RongQing Signed-off-by: Dou Liyang --- arch/x86/kernel/acpi/boot.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/acpi/boot.c b/

Re: [tip:x86/urgent] x86/apic: Fix signedness bug in APIC ID validity checks

Hi Thomas, At 04/10/2018 10:51 PM, tip-bot for Li RongQing wrote: [...] x86/apic: Fix signedness bug in APIC ID validity checks The APIC ID as parsed from ACPI MADT is validity checked with the apic->apic_id_valid() callback, which depends on the selected APIC type. For non X2APIC types APIC

Re: 答复: 答复: [RFC PATCH] x86/acpi: Prevent x2apic id -1 from being accounted

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

Re: 答复: [RFC PATCH] x86/acpi: Prevent x2apic id -1 from being accounted

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

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

Re: [RFC PATCH] x86/acpi: Prevent x2apic id -1 from being accounted

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/

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 w

[PATCH] x86/processor: Remove two legacy function declaration

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

[RESEND PATCH] x86/boot/KASLR: Extend movable_node option for KASLR

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

Re: [PATCH v9 0/5] x86/KASLR: Add parameter kaslr_boot_mem=nn[KMG]@ss[KMG]

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

Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

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

Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

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 mptables by default

Re: [PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map()

Hi Peter, At 03/20/2018 08:39 PM, Peter Zijlstra wrote: On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote: case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids, setup_max_cpus) case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids) case 3: no | ye

Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

Hi Peter, At 03/20/2018 08:37 PM, Peter Zijlstra wrote: On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote: + possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus. + This option sets possible_cpus bits in cpu_possible_map

[PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map()

follow. Isolate them, and check them linearly. No functionary change, Prepare for cutting the number of possible CPUs Signed-off-by: Dou Liyang --- Situations: setup_possible_cpus == -1 | setup_max_cpus == 0 | CONFIG_HOTPLUG_CPU == y | yes | yes

[PATCH 2/5] x86/cpu_hotplug: Update the link of cpu_hotplug.rst

The original cpu_hotplug.txt documents describing CPU hotplug support in Linux kernel. it was moved in to core-api/ and renamed cpu_hotplug.rst. Update it's link in other documents Fixes: ff58fa7f556c ("Documentation: Update CPU hotplug and move it to core-api") Signed-off

[PATCH 5/5] acpi/processor: Make the acpi_duplicate_processor_id() static

The acpi_duplicate_processor_id() is only called in acpi_processor_get_info(), So move it in front of acpi_processor_get_info() and make it static. Signed-off-by: Dou Liyang --- drivers/acpi/acpi_processor.c | 62 +-- include/linux/acpi.h | 3

[PATCH 0/5] x86/cpu_hotplug: one bug fix and four cleanup

), - two cleapup work (the 3th and 5th patch) - a bug fix for CPU hotplug(4th patch) Dou Liyang (5): x86/smpboot: Add the missing description of possible_cpus x86/cpu_hotplug: Update the link of cpu_hotplug.rst x86/smpboot: Make the check code more clear in prefill_possible_map() acpi

[PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()

the walk break after walking pass the first processor. Repace the value with AE_OK which is the standard acpi_status value. Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for processor enumeration") Signed-off-by: Dou Liyang --- drivers/acpi/acpi_processor.c | 4 ++

[PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

Kernel uses the possible_cpus in command line to reset the possible_cpus bits in cpu_possible_map. It doesn't be recorded in the kernel-parameters.txt Add its description in this document, also replace the wrong option additional_cpus with possible_cpus in cpu-gotplug-spec. Signed-off-by

Re: [ACPI / processor] d619c81e24: WARNING:at_include/linux/cpumask.h:#cpumask_test_cpu

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

Re: [PATCH] kernel/cpu: Move cpuhp_is_atomic_state() into #ifdef CONFIG_SMP

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

[PATCH] kernel/cpu: Move cpuhp_is_atomic_state() into #ifdef CONFIG_SMP

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 {

  1   2   3   4   5   6   >