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
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
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
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
---
inc
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
---
inc
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
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
of 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=153543887027997=2
Dou Liyang (3):
genirq/affinity: Add a new interrupt affinity descriptor
irq/affinity: Add
of 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=153543887027997=2
Dou Liyang (3):
genirq/affinity: Add a new interrupt affinity descriptor
irq/affinity: Add
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
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
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=153543887027997=2
- entry = alloc_msi_entry(>dev, nvec, masks);
+ entry =
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=153543887027997=2
- entry = alloc_msi_entry(>dev, nvec, masks);
+ entry =
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
- Create a
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
- Create a
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-by: Dou Liyang
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-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
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
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
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
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
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
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
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
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
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
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 vectors
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 vectors
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
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
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 inter
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 inter
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 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 inter
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 inter
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
rator 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
check
rator 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
check
rator 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 linux-4
rator 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 linux-4
(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.
(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.
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
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
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
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
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 between 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 between 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 +
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 +
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
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
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
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
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
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 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 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/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/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
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
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
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
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
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
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
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
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
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
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
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
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/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/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()
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()
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
1 - 100 of 1151 matches
Mail list logo
