[tip: x86/urgent] x86/asm/64: Align start of __clear_user() loop to 16-bytes

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: bb5570ad3b54e7930997aec76ab68256d5236d94 Gitweb: https://git.kernel.org/tip/bb5570ad3b54e7930997aec76ab68256d5236d94 Author:Matt Fleming AuthorDate:Thu, 18 Jun 2020 11:20:02 +01:00

[PATCH] x86/asm/64: Align start of __clear_user() loop to 16-bytes

m Detector (verified using perf events). Fixes: 1153933703d9 ("x86/asm/64: Micro-optimize __clear_user() - Use immediate constants") Cc: "Grimm, Jon" Cc: "Kumar, Venkataramanan" CC: Jan Kara Cc: # v4.19+ Signed-off-by: Matt Fleming --- arch/x86/lib/usercopy

Re: [PATCH v2] perf ordered_events: Optimise event object reuse

On Wed, 27 May, at 12:25:33PM, Jiri Olsa wrote: > On Tue, May 26, 2020 at 02:59:28PM +0100, Matt Fleming wrote: > > +/* > > + * Allocate a new event object from the free event cache. > > + * > > + * Find the first address range in the cache and carve out enough bytes &

[PATCH v2] perf ordered_events: Optimise event object reuse

9+7.7% 6475305954370500MB 25.64823.753+7.4% 14218430569416 1000MB 52.80049.036+7.1% 26760562279427 2000MB 97.169 90.129+7.2% Signed-off-by: Matt Fleming --- Changes in v2: - Add --free-event-list parameter to fallback to the linked-list impl

Re: [PATCH] perf ordered_events: Optimise event object reuse

On Wed, 20 May, at 11:52:34PM, Jiri Olsa wrote: > On Wed, May 20, 2020 at 02:00:49PM +0100, Matt Fleming wrote: > > > > Nope, the tests in this file are unit tests so I'm testing > > free_cache_{get,put} which are file-local functions by #include'ing > > ordered-e

Re: [PATCH] perf ordered_events: Optimise event object reuse

On Mon, 18 May, at 02:04:08PM, Jiri Olsa wrote: > On Fri, May 15, 2020 at 10:01:51PM +0100, Matt Fleming wrote: > > ordered_event objects can be placed on the free object cache list in any > > order which means future allocations may not return objects at > > sequentia

[PATCH] perf ordered_events: Optimise event object reuse

29MB 1.637 1.587+3.0% 3280413919096253MB 13.38112.349+7.7% 6475305954370500MB 25.64823.753+7.4% 14218430569416 1000MB 52.80049.036+7.1% 26760562279427 2000MB 97.169 90.129+7.2% Signed-off-by: Matt Fleming --- tools/include/l

Re: [PATCH 0/3] Recalculate per-cpu page allocator batch and high limits after deferred meminit

On Fri, 18 Oct, at 01:54:49PM, Mel Gorman wrote: > On Fri, Oct 18, 2019 at 12:58:49PM +0100, Matt Fleming wrote: > > On Fri, 18 Oct, at 11:56:03AM, Mel Gorman wrote: > > > A private report stated that system CPU usage was excessive on an AMD > > > EPYC 2 machine while

Re: [PATCH 0/3] Recalculate per-cpu page allocator batch and high limits after deferred meminit

On Fri, 18 Oct, at 11:56:03AM, Mel Gorman wrote: > A private report stated that system CPU usage was excessive on an AMD > EPYC 2 machine while building kernels with much longer build times than > expected. The issue is partially explained by high zone lock contention > due to the per-cpu page

Re: [PATCH 3/3] mm, pcpu: Make zone pcp updates and reset internal to the mm

ux/mm.h | 3 --- > mm/internal.h | 3 +++ > 2 files changed, 3 insertions(+), 3 deletions(-) Tested-by: Matt Fleming

Re: [PATCH 1/3] mm, pcp: Share common code between memory hotplug and percpu sysctl handler

ge. > > Signed-off-by: Mel Gorman > --- > mm/page_alloc.c | 23 --- > 1 file changed, 12 insertions(+), 11 deletions(-) Tested-by: Matt Fleming

Re: [PATCH 2/3] mm, meminit: Recalculate pcpu batch and high limits after init completes

he patch reduces system CPU usage by 69.16% and total build time by > 27.06%. The variance of system CPU usage is also much reduced. > > Cc: sta...@vger.kernel.org # v4.15+ > Signed-off-by: Mel Gorman > --- > mm/page_alloc.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Tested-by: Matt Fleming

Re: [PATCH v4 2/2] sched/topology: Improve load balancing on AMD EPYC

On Mon, 07 Oct, at 08:28:16AM, Guenter Roeck wrote: > > This patch causes build errors on systems where NUMA does not depend on SMP, > for example MIPS and PPC. For example, building mips:ip27_defconfig with SMP > disabled results in > > mips-linux-ld: mm/page_alloc.o: in function

[tip: sched/core] sched/topology: Improve load balancing on AMD EPYC systems

The following commit has been merged into the sched/core branch of tip: Commit-ID: a55c7454a8c887b226a01d7eed088ccb5374d81e Gitweb: https://git.kernel.org/tip/a55c7454a8c887b226a01d7eed088ccb5374d81e Author:Matt Fleming AuthorDate:Thu, 08 Aug 2019 20:53:01 +01:00

[tip: sched/core] arch, ia64: Make NUMA select SMP

The following commit has been merged into the sched/core branch of tip: Commit-ID: a2cbfd46559e809c8165773b7fe8afa058b35414 Gitweb: https://git.kernel.org/tip/a2cbfd46559e809c8165773b7fe8afa058b35414 Author:Matt Fleming AuthorDate:Thu, 08 Aug 2019 20:53:00 +01:00

[PATCH v4 2/2] sched/topology: Improve load balancing on AMD EPYC

e balancer kicks in after a few seconds and forcibly moves some threads to node 4. Override node_reclaim_distance for AMD Zen. Signed-off-by: Matt Fleming Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mel Gorman Cc: suravee.suthikulpa...@amd.com Cc: Borislav Petkov Cc: thomas.lenda...@amd.com

[PATCH 1/2] ia64: Make NUMA select SMP

-off-by: Matt Fleming Cc: Tony Luck Cc: Rik van Riel Cc: Peter Zijlstra --- arch/ia64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 7468d8e50467..997baba02b70 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -389,6 +389,7

[PATCH v4 0/2] sched: Improve load balancing on AMD EPYC

' page_alloc.c:(.text+0x7931): undefined reference to `node_reclaim_distance' Matt Fleming (2): ia64: Make NUMA select SMP sched/topology: Improve load balancing on AMD EPYC arch/ia64/Kconfig | 1 + arch/x86/kernel/cpu/amd.c | 5 + include/linux/topology.h | 14

Re: [PATCH v3] sched/topology: Improve load balancing on AMD EPYC

ith the active load balancer kicking in after a few seconds, but I suspect that is related to the use of group capacity elsewhere in the load balancer code (like update_sg_lb_stats()). -- Matt Fleming SUSE Performance Team

[PATCH v3] sched/topology: Improve load balancing on AMD EPYC

e balancer kicks in after a few seconds and forcibly moves some threads to node 4. Override node_reclaim_distance for AMD Zen. Signed-off-by: Matt Fleming Cc: "Suthikulpanit, Suravee" Cc: Mel Gorman Cc: "Lendacky, Thomas" Cc: Borislav Petkov --- arch/x86/kernel/cpu

Re: [PATCH] sched/topology: Improve load balancing on AMD EPYC

On Wed, 26 Jun, at 09:18:01PM, Suthikulpanit, Suravee wrote: > > We use 16 to designate 1-hop latency (for different node within the same > socket). > For across-socket access, since the latency is greater, we set the latency to > 32 > (twice the latency of 1-hop) not aware of the

Re: [PATCH] sched/topology: Improve load balancing on AMD EPYC

On Tue, 18 Jun, at 02:33:18PM, Peter Zijlstra wrote: > On Tue, Jun 18, 2019 at 11:43:19AM +0100, Matt Fleming wrote: > > This works for me under all my tests. Thoughts? > > > > --->8--- > > > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/ker

Re: [PATCH] sched/topology: Improve load balancing on AMD EPYC

On Tue, 11 Jun, at 05:22:21PM, Lendacky, Thomas wrote: > On 6/10/19 4:26 PM, Matt Fleming wrote: > > On Wed, 05 Jun, at 08:00:35PM, Peter Zijlstra wrote: > >> > >> And then we had two magic values :/ > >> > >> Should we not 'fix' RECLAIM_DISTANCE for

Re: [PATCH] sched/topology: Improve load balancing on AMD EPYC

On Wed, 05 Jun, at 08:00:35PM, Peter Zijlstra wrote: > > And then we had two magic values :/ > > Should we not 'fix' RECLAIM_DISTANCE for EPYC or something? Because > surely, if we want to load-balance agressively over 30, then so too > should we do node_reclaim() I'm thikning. Yeah we can fix

[PATCH] sched/topology: Improve load balancing on AMD EPYC

e balancer kicks in after a few seconds and forcibly moves some threads to node 4. Update the code in sd_init() to account for modern node distances, and maintaining backward-compatible behaviour by respecting RECLAIM_DISTANCE for distances more than 2 hops. Signed-off-by: Matt Fleming Cc: &quo

Re: [PATCH] doc: add boot protocol 2.13 description to Documentation/x86/boot.txt

T > > The traditional memory map for the kernel loader, used for Image or > -- > 2.16.4 Not sure if this has already been picked up but... Reviewed-by: Matt Fleming

Re: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

On Sat, 22 Dec, at 12:07:48PM, Ard Biesheuvel wrote: > On Fri, 21 Dec 2018 at 20:29, Borislav Petkov wrote: > > > > On Fri, Dec 21, 2018 at 06:26:23PM +0100, Ard Biesheuvel wrote: > > > On Fri, 21 Dec 2018 at 18:13, Borislav Petkov wrote: > > > > > > > > On Fri, Dec 21, 2018 at 06:02:29PM +0100,

Re: [PATCH] sched/fair: Avoid divide by zero when rebalancing domains

On Thu, 05 Jul, at 05:54:02PM, Valentin Schneider wrote: > On 05/07/18 14:27, Matt Fleming wrote: > > On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote: > >> Hi, > >> > >> On 04/07/18 15:24, Matt Fleming wrote: > >>> It's possible that th

Re: [PATCH] sched/fair: Avoid divide by zero when rebalancing domains

On Thu, 05 Jul, at 05:54:02PM, Valentin Schneider wrote: > On 05/07/18 14:27, Matt Fleming wrote: > > On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote: > >> Hi, > >> > >> On 04/07/18 15:24, Matt Fleming wrote: > >>> It's possible that th

Re: [lkp-robot] [sched/fair] fbd5188493: WARNING:inconsistent_lock_state

On Thu, 05 Jul, at 02:24:58PM, Matt Fleming wrote: > > Hmm.. it still looks to me like we should be saving and restoring IRQs > since this can be called from IRQ context, no? > > The patch was a forward-port from one of our SLE kernels, and I messed > up the IRQ flag balancing

Re: [lkp-robot] [sched/fair] fbd5188493: WARNING:inconsistent_lock_state

On Thu, 05 Jul, at 02:24:58PM, Matt Fleming wrote: > > Hmm.. it still looks to me like we should be saving and restoring IRQs > since this can be called from IRQ context, no? > > The patch was a forward-port from one of our SLE kernels, and I messed > up the IRQ flag balancing

Re: [PATCH] sched/fair: Avoid divide by zero when rebalancing domains

On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote: > Hi, > > On 04/07/18 15:24, Matt Fleming wrote: > > It's possible that the CPU doing nohz idle balance hasn't had its own > > load updated for many seconds. This can lead to huge deltas between > > rq-&g

Re: [PATCH] sched/fair: Avoid divide by zero when rebalancing domains

On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote: > Hi, > > On 04/07/18 15:24, Matt Fleming wrote: > > It's possible that the CPU doing nohz idle balance hasn't had its own > > load updated for many seconds. This can lead to huge deltas between > > rq-&g

Re: [lkp-robot] [sched/fair] fbd5188493: WARNING:inconsistent_lock_state

On Thu, 05 Jul, at 11:52:21AM, Dietmar Eggemann wrote: > > Moving the code from _nohz_idle_balance to nohz_idle_balance let it disappear: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 02be51c9dcc1..070924f07c68 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c >

Re: [lkp-robot] [sched/fair] fbd5188493: WARNING:inconsistent_lock_state

On Thu, 05 Jul, at 11:52:21AM, Dietmar Eggemann wrote: > > Moving the code from _nohz_idle_balance to nohz_idle_balance let it disappear: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 02be51c9dcc1..070924f07c68 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c >

[PATCH] sched/fair: Avoid divide by zero when rebalancing domains

braith Cc: Peter Zijlstra Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2f0a0be4d344..2c81662c858a 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9597,6 +9

[PATCH] sched/fair: Avoid divide by zero when rebalancing domains

braith Cc: Peter Zijlstra Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2f0a0be4d344..2c81662c858a 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9597,6 +9

Re: [RFC 00/11] select_idle_sibling rework

On Wed, 30 May, at 04:22:36PM, Peter Zijlstra wrote: > Hi all, > > This is all still very preliminary and could all still go up in flames (it has > only seen hackbench so far). This is mostly the same code I posted yesterday, > but hopefully in a more readable form. > > This fixes the SIS_PROP

Re: [RFC 00/11] select_idle_sibling rework

On Wed, 30 May, at 04:22:36PM, Peter Zijlstra wrote: > Hi all, > > This is all still very preliminary and could all still go up in flames (it has > only seen hackbench so far). This is mostly the same code I posted yesterday, > but hopefully in a more readable form. > > This fixes the SIS_PROP

Re: cpu stopper threads and load balancing leads to deadlock

On Fri, 20 Apr, at 11:50:05AM, Peter Zijlstra wrote: > On Tue, Apr 17, 2018 at 03:21:19PM +0100, Matt Fleming wrote: > > Hi guys, > > > > We've seen a bug in one of our SLE kernels where the cpu stopper > > thread ("migration/15") is entering idle balanc

Re: cpu stopper threads and load balancing leads to deadlock

On Fri, 20 Apr, at 11:50:05AM, Peter Zijlstra wrote: > On Tue, Apr 17, 2018 at 03:21:19PM +0100, Matt Fleming wrote: > > Hi guys, > > > > We've seen a bug in one of our SLE kernels where the cpu stopper > > thread ("migration/15") is entering idle balanc

cpu stopper threads and load balancing leads to deadlock

Hi guys, We've seen a bug in one of our SLE kernels where the cpu stopper thread ("migration/15") is entering idle balance. This then triggers active load balance. At the same time, a task on another CPU triggers a page fault and NUMA balancing kicks in to try and migrate the task closer to the

cpu stopper threads and load balancing leads to deadlock

Hi guys, We've seen a bug in one of our SLE kernels where the cpu stopper thread ("migration/15") is entering idle balance. This then triggers active load balance. At the same time, a task on another CPU triggers a page fault and NUMA balancing kicks in to try and migrate the task closer to the

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

c > +++ b/kernel/sched/rt.c > @@ -839,6 +839,8 @@ static int do_sched_rt_period_timer(struct rt_bandwidth > *rt_b, int overrun) > continue; > > raw_spin_lock(>lock); > + update_rq_clock(rq); > + >

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

kernel/sched/rt.c > @@ -839,6 +839,8 @@ static int do_sched_rt_period_timer(struct rt_bandwidth > *rt_b, int overrun) > continue; > > raw_spin_lock(>lock); > + update_rq_clock(rq); > + > if (rt_rq->rt_time) { > u64 runtime; Looks good to me. Reviewed-by: Matt Fleming

Re: [PATCH RFC v2] sched: Minimize the idle cpu selection race window.

On Tue, 05 Dec, at 01:09:07PM, Atish Patra wrote: > Currently, multiple tasks can wakeup on same cpu from > select_idle_sibiling() path in case they wakeup simulatenously > and last ran on the same llc. This happens because an idle cpu > is not updated until idle task is scheduled out. Any task

Re: [PATCH RFC v2] sched: Minimize the idle cpu selection race window.

On Tue, 05 Dec, at 01:09:07PM, Atish Patra wrote: > Currently, multiple tasks can wakeup on same cpu from > select_idle_sibiling() path in case they wakeup simulatenously > and last ran on the same llc. This happens because an idle cpu > is not updated until idle task is scheduled out. Any task

Re: [PATCH V4 0/3] Use mm_struct and switch_mm() instead of manually

nstead we can use helper function > efi_switch_mm() to do this. This improves readability and maintainability. > Also, instead of maintaining a separate struct "efi_scratch" to store/restore > efi_pgd, we can use mm_struct to do this. FWIW this series looks OK to me. Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [PATCH V4 0/3] Use mm_struct and switch_mm() instead of manually

ion > efi_switch_mm() to do this. This improves readability and maintainability. > Also, instead of maintaining a separate struct "efi_scratch" to store/restore > efi_pgd, we can use mm_struct to do this. FWIW this series looks OK to me. Reviewed-by: Matt Fleming

[tip:efi/core] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

Commit-ID: 81b60dbff04980a45b348c5b5eeca2713d4594ca Gitweb: https://git.kernel.org/tip/81b60dbff04980a45b348c5b5eeca2713d4594ca Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Wed, 3 Jan 2018 09:44:17 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed

[tip:efi/core] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

Commit-ID: 81b60dbff04980a45b348c5b5eeca2713d4594ca Gitweb: https://git.kernel.org/tip/81b60dbff04980a45b348c5b5eeca2713d4594ca Author: Matt Fleming AuthorDate: Wed, 3 Jan 2018 09:44:17 + Committer: Ingo Molnar CommitDate: Wed, 3 Jan 2018 14:03:18 +0100 MAINTAINERS: Remove Matt

Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

On Wed, 03 Jan, at 10:13:55AM, Ard Biesheuvel wrote: > On 3 January 2018 at 09:44, Matt Fleming <m...@codeblueprint.co.uk> wrote: > > Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks > > as maintainers for the EFI test driver and efivarfs file syste

Re: [PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

On Wed, 03 Jan, at 10:13:55AM, Ard Biesheuvel wrote: > On 3 January 2018 at 09:44, Matt Fleming wrote: > > Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks > > as maintainers for the EFI test driver and efivarfs file system. > > > > Signed-off-b

[PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks as maintainers for the EFI test driver and efivarfs file system. Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- MAINTAINERS | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) Ard, if you want

[PATCH] MAINTAINERS: Remove Matt Fleming as EFI co-maintainer

Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks as maintainers for the EFI test driver and efivarfs file system. Signed-off-by: Matt Fleming --- MAINTAINERS | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) Ard, if you want to add yourself as co-maintainer

Re: [PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

On Sat, 16 Dec, at 12:19:53PM, Dave Young wrote: > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no > chance to run because the code path is before parse_early_param(). > I believe it worked when the param was introduced but probably later > some other changes caused the wrong

Re: [PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

On Sat, 16 Dec, at 12:19:53PM, Dave Young wrote: > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no > chance to run because the code path is before parse_early_param(). > I believe it worked when the param was introduced but probably later > some other changes caused the wrong

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

On Sat, 16 Dec, at 03:06:32PM, Ingo Molnar wrote: > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > x86_init.oem.arch_setup(); > > > @@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p) > > > > > > parse_earl

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

On Sat, 16 Dec, at 03:06:32PM, Ingo Molnar wrote: > > * Matt Fleming wrote: > > > > x86_init.oem.arch_setup(); > > > @@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p) > > > > > > parse_early_para

Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all

On Sat, 09 Dec, at 04:52:52PM, Vincent Legoll wrote: > No need to get into the submenu to disable all related > config entries. > > This makes it easier to disable all EFI config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside

Re: [PATCH] efi: make EFI a menuconfig to ease disabling it all

On Sat, 09 Dec, at 04:52:52PM, Vincent Legoll wrote: > No need to get into the submenu to disable all related > config entries. > > This makes it easier to disable all EFI config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the outside

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

On Thu, 14 Dec, at 06:41:19PM, Dave Young wrote: > On 11/30/17 at 01:23pm, Dave Young wrote: > > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no > > chance to run because the code path is before parse_early_param(). > > I believe it worked when the param was introduced but

Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap

On Thu, 14 Dec, at 06:41:19PM, Dave Young wrote: > On 11/30/17 at 01:23pm, Dave Young wrote: > > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no > > chance to run because the code path is before parse_early_param(). > > I believe it worked when the param was introduced but

Re: [PATCH] efi: Use PTR_ERR_OR_ZERO()

On Tue, 28 Nov, at 10:39:37PM, Vasyl Gomonovych wrote: > Fix ptr_ret.cocci warnings: > drivers/firmware/efi/efi.c:610:8-14: WARNING: PTR_ERR_OR_ZERO can be used > > Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR > > Generated by: scripts/coccinelle/api/ptr_ret.cocci > >

Re: [PATCH] efi: Use PTR_ERR_OR_ZERO()

On Tue, 28 Nov, at 10:39:37PM, Vasyl Gomonovych wrote: > Fix ptr_ret.cocci warnings: > drivers/firmware/efi/efi.c:610:8-14: WARNING: PTR_ERR_OR_ZERO can be used > > Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR > > Generated by: scripts/coccinelle/api/ptr_ret.cocci > >

Re: [GIT PULL] hash addresses printed with %p

(Cc'ing Dave since this is used for kexec on EFI) On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > On 1 December 2017 at 09:48, Greg Kroah-Hartman > wrote: > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote: > >> On 30 November 2017 at 17:10,

Re: [GIT PULL] hash addresses printed with %p

(Cc'ing Dave since this is used for kexec on EFI) On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > On 1 December 2017 at 09:48, Greg Kroah-Hartman > wrote: > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote: > >> On 30 November 2017 at 17:10, Greg Kroah-Hartman > >> wrote:

Re: sysbench throughput degradation in 4.13+

On Fri, 06 Oct, at 11:36:23AM, Matt Fleming wrote: > > It's a similar story for hackbench-threads-{pipes,sockets}, i.e. pipes > regress but performance is restored for sockets. > > Of course, like a dope, I forgot to re-run netperf with your WA_WEIGHT > patch. So I've

Re: sysbench throughput degradation in 4.13+

On Fri, 06 Oct, at 11:36:23AM, Matt Fleming wrote: > > It's a similar story for hackbench-threads-{pipes,sockets}, i.e. pipes > regress but performance is restored for sockets. > > Of course, like a dope, I forgot to re-run netperf with your WA_WEIGHT > patch. So I've

Re: [PATCH] efi/capsule-loader: pr_err() strings should end with newlines

On Mon, 25 Sep, at 04:17:23PM, Arvind Yadav wrote: > pr_err() messages should terminated with a new-line to avoid > other messages being concatenated onto the end. > > Signed-off-by: Arvind Yadav > --- > drivers/firmware/efi/capsule-loader.c | 2 +- > 1 file changed,

Re: [PATCH] efi/capsule-loader: pr_err() strings should end with newlines

On Mon, 25 Sep, at 04:17:23PM, Arvind Yadav wrote: > pr_err() messages should terminated with a new-line to avoid > other messages being concatenated onto the end. > > Signed-off-by: Arvind Yadav > --- > drivers/firmware/efi/capsule-loader.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: sysbench throughput degradation in 4.13+

On Wed, 04 Oct, at 06:18:50PM, Peter Zijlstra wrote: > On Tue, Oct 03, 2017 at 10:39:32AM +0200, Peter Zijlstra wrote: > > So I was waiting for Rik, who promised to run a bunch of NUMA workloads > > over the weekend. > > > > The trivial thing regresses a wee bit on the overloaded case, I've not >

Re: sysbench throughput degradation in 4.13+

On Wed, 04 Oct, at 06:18:50PM, Peter Zijlstra wrote: > On Tue, Oct 03, 2017 at 10:39:32AM +0200, Peter Zijlstra wrote: > > So I was waiting for Rik, who promised to run a bunch of NUMA workloads > > over the weekend. > > > > The trivial thing regresses a wee bit on the overloaded case, I've not >

Re: sysbench throughput degradation in 4.13+

On Wed, 27 Sep, at 01:58:20PM, Rik van Riel wrote: > > I like the simplicity of your approach! I hope it does not break > stuff like netperf... > > I have been working on the patch below, which is much less optimistic > about when to do an affine wakeup than before. Running netperf for this

Re: sysbench throughput degradation in 4.13+

On Wed, 27 Sep, at 01:58:20PM, Rik van Riel wrote: > > I like the simplicity of your approach! I hope it does not break > stuff like netperf... > > I have been working on the patch below, which is much less optimistic > about when to do an affine wakeup than before. Running netperf for this

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Wed, 16 Aug, at 12:03:22PM, Mark Rutland wrote: > > I'd expect we'd abort at a higher level, not taking any sample. i.e. > we'd have the core overflow handler check in_funny_mm(), and if so, skip > the sample, as with the skid case. FYI, this is my preferred solution for x86 too.

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Wed, 16 Aug, at 12:03:22PM, Mark Rutland wrote: > > I'd expect we'd abort at a higher level, not taking any sample. i.e. > we'd have the core overflow handler check in_funny_mm(), and if so, skip > the sample, as with the skid case. FYI, this is my preferred solution for x86 too.

Re: [PATCH v9 1/2] efi: Introduce efi_early_memdesc_ptr to get pointer to memmap descriptor

On Mon, 14 Aug, at 10:54:23PM, Baoquan He wrote: > The existing map iteration helper for_each_efi_memory_desc_in_map can > only be used after OS initializes EFI to fill data of struct efi_memory_map. Should this say "EFI subsystem"? The firmware doesn't care about the kernel's internal data

Re: [PATCH v9 1/2] efi: Introduce efi_early_memdesc_ptr to get pointer to memmap descriptor

On Mon, 14 Aug, at 10:54:23PM, Baoquan He wrote: > The existing map iteration helper for_each_efi_memory_desc_in_map can > only be used after OS initializes EFI to fill data of struct efi_memory_map. Should this say "EFI subsystem"? The firmware doesn't care about the kernel's internal data

Re: [PATCH] x86/efi: page align EFI ROM image ranges

On Wed, 02 Aug, at 11:41:38AM, Stuart Hayes wrote: > (Resend because I mistyped the maintainer's email address the first time.) > > The kernel's EFI stub locates and copies EFI ROM images into memory, > which it allocates using the byte-granular EFI allocate_pool > function. These memory ranges

Re: [PATCH] x86/efi: page align EFI ROM image ranges

On Wed, 02 Aug, at 11:41:38AM, Stuart Hayes wrote: > (Resend because I mistyped the maintainer's email address the first time.) > > The kernel's EFI stub locates and copies EFI ROM images into memory, > which it allocates using the byte-granular EFI allocate_pool > function. These memory ranges

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Fri, 04 Aug, at 07:40:05PM, Baoquan He wrote: > On 08/04/17 at 12:23pm, Matt Fleming wrote: > > On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote: > > > Hi Matt, > > > > > > On 07/28/17 at 11:55am, Ingo Molnar wrote: > > > > > &g

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Fri, 04 Aug, at 07:40:05PM, Baoquan He wrote: > On 08/04/17 at 12:23pm, Matt Fleming wrote: > > On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote: > > > Hi Matt, > > > > > > On 07/28/17 at 11:55am, Ingo Molnar wrote: > > > > > > > &

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote: > Hi Matt, > > On 07/28/17 at 11:55am, Ingo Molnar wrote: > > > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > > On Fri, 21 Jul, at 09:19:56PM, Baoquan He wrote: > > > > > >

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote: > Hi Matt, > > On 07/28/17 at 11:55am, Ingo Molnar wrote: > > > > * Matt Fleming wrote: > > > > > On Fri, 21 Jul, at 09:19:56PM, Baoquan He wrote: > > > > > > > > There are

Re: [PATCH v4.4.y] sched/cgroup: Move sched_online_group() back into css_online() to fix crash

On Wed, 26 Jul, at 07:35:51AM, Greg KH wrote: > > If it needs a backport and a simple cherry-pick does not work, yes > please. Oh, it turns out cherry-picking commit 96b777452d88 to 4.9-stable works just fine.

Re: [PATCH v4.4.y] sched/cgroup: Move sched_online_group() back into css_online() to fix crash

On Wed, 26 Jul, at 07:35:51AM, Greg KH wrote: > > If it needs a backport and a simple cherry-pick does not work, yes > please. Oh, it turns out cherry-picking commit 96b777452d88 to 4.9-stable works just fine.

Re: [PATCH v4.4.y] sched/cgroup: Move sched_online_group() back into css_online() to fix crash

On Tue, 25 Jul, at 11:04:39AM, Greg KH wrote: > On Thu, Jul 20, 2017 at 02:53:09PM +0100, Matt Fleming wrote: > > From: Konstantin Khlebnikov <khlebni...@yandex-team.ru> > > > > commit 96b777452d8881480fd5be50112f791c17db4b6b upstream. > > > > Commit: >

Re: [PATCH v4.4.y] sched/cgroup: Move sched_online_group() back into css_online() to fix crash

On Tue, 25 Jul, at 11:04:39AM, Greg KH wrote: > On Thu, Jul 20, 2017 at 02:53:09PM +0100, Matt Fleming wrote: > > From: Konstantin Khlebnikov > > > > commit 96b777452d8881480fd5be50112f791c17db4b6b upstream. > > > > Commit: > > > > 2f5177f0fd7

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Fri, 21 Jul, at 09:19:56PM, Baoquan He wrote: > > There are places where the efi map is getting and used like this. E.g > in efi_high_alloc() of drivers/firmware/efi/libstub/efi-stub-helper.c. > EFI developers worry the size of efi_memory_desc_t could not be the same > as e->efi_memdesc_size? >

Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On Fri, 21 Jul, at 09:19:56PM, Baoquan He wrote: > > There are places where the efi map is getting and used like this. E.g > in efi_high_alloc() of drivers/firmware/efi/libstub/efi-stub-helper.c. > EFI developers worry the size of efi_memory_desc_t could not be the same > as e->efi_memdesc_size? >

Re: [PATCH v3 2/2] x86/efi: clean up dead code around efi_reserve_boot_services()

On Mon, 10 Jul, at 02:51:36PM, Naoya Horiguchi wrote: > EFI_BOOT_SERVICES_{CODE|DATA} regions never overlap the kernel now, > so we can clean up the check in efi_reserve_boot_services(). > > Signed-off-by: Naoya Horiguchi > --- > arch/x86/platform/efi/quirks.c | 23

Re: [PATCH v3 2/2] x86/efi: clean up dead code around efi_reserve_boot_services()

On Mon, 10 Jul, at 02:51:36PM, Naoya Horiguchi wrote: > EFI_BOOT_SERVICES_{CODE|DATA} regions never overlap the kernel now, > so we can clean up the check in efi_reserve_boot_services(). > > Signed-off-by: Naoya Horiguchi > --- > arch/x86/platform/efi/quirks.c | 23 +-- > 1

Re: [PATCH v3 1/2] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

On Mon, 10 Jul, at 02:51:35PM, Naoya Horiguchi wrote: > KASLR chooses kernel location from E820_TYPE_RAM regions by walking over > e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and > EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to > UEFI spec, all memory

Re: [PATCH v3 1/2] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

On Mon, 10 Jul, at 02:51:35PM, Naoya Horiguchi wrote: > KASLR chooses kernel location from E820_TYPE_RAM regions by walking over > e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and > EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to > UEFI spec, all memory

[PATCH v4.4.y] sched/cgroup: Move sched_online_group() back into css_online() to fix crash

917.5302984537258726349.stgit@buzz Signed-off-by: Ingo Molnar <mi...@kernel.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/core.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 20253dbc

[PATCH v4.4.y] sched/cgroup: Move sched_online_group() back into css_online() to fix crash

up cgroup teardown/init") Link: http://lkml.kernel.org/r/148655324740.424917.5302984537258726349.stgit@buzz Signed-off-by: Ingo Molnar Signed-off-by: Matt Fleming --- kernel/sched/core.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.

Re: [PATCH v4 00/10] PCID and improved laziness

On Tue, 11 Jul, at 08:00:47AM, Andy Lutomirski wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git/ > > I did: > > $ ./context_switch_latency_64 0 process same Ah, that's better. I see about a 3.3% speedup with your patches when running the context-switch benchmark.

Re: [PATCH v4 00/10] PCID and improved laziness

On Tue, 11 Jul, at 08:00:47AM, Andy Lutomirski wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git/ > > I did: > > $ ./context_switch_latency_64 0 process same Ah, that's better. I see about a 3.3% speedup with your patches when running the context-switch benchmark.

Re: [PATCH v4 00/10] PCID and improved laziness

On Fri, 30 Jun, at 01:44:22PM, Matt Fleming wrote: > On Thu, 29 Jun, at 08:53:12AM, Andy Lutomirski wrote: > > *** Ingo, even if this misses 4.13, please apply the first patch before > > *** the merge window. > > > > There are three performance benefits here: >

  1   2   3   4   5   6   7   8   9   10   >