Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

On Mon, 2016-10-17 at 19:18 +0200, Mike Galbraith wrote: > BTW, 4.8 either needs the btrfs deadlock fix (0ccd05285e7f) or the LTP > testcase has to be hacked to not test btrfs. It also fails the first > time it's run in 4.8/4.8-rt, doesn't do that in master/tip-rt. Belay that, the

Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

On Mon, 2016-10-17 at 19:18 +0200, Mike Galbraith wrote: > BTW, 4.8 either needs the btrfs deadlock fix (0ccd05285e7f) or the LTP > testcase has to be hacked to not test btrfs. It also fails the first > time it's run in 4.8/4.8-rt, doesn't do that in master/tip-rt. Belay that, the

Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

On Mon, 2016-10-17 at 18:29 +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-17 18:19:00 [+0200], Mike Galbraith wrote: > > I used a local lock first, but lockdep was unhappy with it. Ok, > > back > > to the drawing board. Seems to work, but... > > locallock

Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

On Mon, 2016-10-17 at 18:29 +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-17 18:19:00 [+0200], Mike Galbraith wrote: > > I used a local lock first, but lockdep was unhappy with it. Ok, > > back > > to the drawing board. Seems to work, but... > > locallock

Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

On Mon, 2016-10-17 at 16:24 +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote: > > > > In v4.7, the driver switched to percpu compression streams, disabling > > preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead. &g

Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

On Mon, 2016-10-17 at 16:24 +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote: > > > > In v4.7, the driver switched to percpu compression streams, disabling > > preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead. &g

Re: [patch ]mm/zs_malloc: Fix bit spinlock replacement

On Mon, 2016-10-17 at 17:15 +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-16 05:18:03 [+0200], Mike Galbraith wrote: > > > > Do not alter HANDLE_SIZE, memory corruption ensues. The handle is > > a pointer, allocate space for the struct it points to and align it >

Re: [patch ]mm/zs_malloc: Fix bit spinlock replacement

On Mon, 2016-10-17 at 17:15 +0200, Sebastian Andrzej Siewior wrote: > On 2016-10-16 05:18:03 [+0200], Mike Galbraith wrote: > > > > Do not alter HANDLE_SIZE, memory corruption ensues. The handle is > > a pointer, allocate space for the struct it points to and align it >

[patch ]mm/zs_malloc: Fix bit spinlock replacement

Do not alter HANDLE_SIZE, memory corruption ensues. The handle is a pointer, allocate space for the struct it points to and align it ZS_ALIGN. Also, when accessing the struct, mask HANDLE_PIN_BIT. Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com> --- mm/zsmalloc.c

[patch ]mm/zs_malloc: Fix bit spinlock replacement

Do not alter HANDLE_SIZE, memory corruption ensues. The handle is a pointer, allocate space for the struct it points to and align it ZS_ALIGN. Also, when accessing the struct, mask HANDLE_PIN_BIT. Signed-off-by: Mike Galbraith --- mm/zsmalloc.c | 13 - 1 file changed, 8

[patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

In v4.7, the driver switched to percpu compression streams, disabling preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead. Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com> --- drivers/block/zram/zcomp.c |4 ++-- 1 file changed, 2 insertions(+), 2 del

[patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

In v4.7, the driver switched to percpu compression streams, disabling preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead. Signed-off-by: Mike Galbraith --- drivers/block/zram/zcomp.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/block/zram/zcomp.c

[patch] drivers,connector: Protect send_msg() with a local lock for RT

] [] proc_exit_connector+0xf8/0x140 [ 6496.323119] [] do_exit+0x5d1/0xba0 [ 6496.323122] [] do_group_exit+0x4c/0xc0 [ 6496.323125] [] SyS_exit_group+0x14/0x20 [ 6496.323127] [] entry_SYSCALL_64_fastpath+0x1a/0xa4 Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com> --- drivers/connector/cn_

[patch] drivers,connector: Protect send_msg() with a local lock for RT

] [] proc_exit_connector+0xf8/0x140 [ 6496.323119] [] do_exit+0x5d1/0xba0 [ 6496.323122] [] do_group_exit+0x4c/0xc0 [ 6496.323125] [] SyS_exit_group+0x14/0x20 [ 6496.323127] [] entry_SYSCALL_64_fastpath+0x1a/0xa4 Signed-off-by: Mike Galbraith --- drivers/connector/cn_proc.c |7 +-- 1 file

[patch] ftrace: Fix latency trace header alignment

Line up helper arrows to the right column. Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com> --- kernel/trace/trace.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2896,17 +2

[patch] ftrace: Fix latency trace header alignment

Line up helper arrows to the right column. Signed-off-by: Mike Galbraith --- kernel/trace/trace.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2896,17 +2896,17 @@ get_total_entries(struct trace_buffer

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

On Sat, 2016-10-08 at 13:37 +0200, Vincent Guittot wrote: > On 8 October 2016 at 10:39, Ingo Molnar wrote: > > > > * Peter Zijlstra wrote: > > > > > On Fri, Oct 07, 2016 at 03:38:23PM -0400, Joseph Salisbury wrote: > > > > Hello Peter, > > > > > > > > A

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

On Sat, 2016-10-08 at 13:37 +0200, Vincent Guittot wrote: > On 8 October 2016 at 10:39, Ingo Molnar wrote: > > > > * Peter Zijlstra wrote: > > > > > On Fri, Oct 07, 2016 at 03:38:23PM -0400, Joseph Salisbury wrote: > > > > Hello Peter, > > > > > > > > A kernel bug report was opened against

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-09-30 at 11:06 +0200, Tejun Heo wrote: > Hello, Mike. > > On Sat, Sep 10, 2016 at 12:08:57PM +0200, Mike Galbraith wrote: > > On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > > > > > As for your example, who performs the cgroup setup and configurat

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-09-30 at 11:06 +0200, Tejun Heo wrote: > Hello, Mike. > > On Sat, Sep 10, 2016 at 12:08:57PM +0200, Mike Galbraith wrote: > > On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > > > > > As for your example, who performs the cgroup setup and configurat

Re: [PATCH 3.12 000/119] 3.12.64-stable review

This one seems to be missing. 135e8c9250dd sched/core: Fix a race between try_to_wake_up() and a woken up task

Re: [PATCH 3.12 000/119] 3.12.64-stable review

This one seems to be missing. 135e8c9250dd sched/core: Fix a race between try_to_wake_up() and a woken up task

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 15:35 -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Thomas Gleixner wrote: > > Can you please provide your .config and the dmesg of a bad and a good run? > > Don't bother. I found it. > > It's a merge artifact. So git bisect pointing at the merge commit is > entirely

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 15:35 -0400, Thomas Gleixner wrote: > On Mon, 26 Sep 2016, Thomas Gleixner wrote: > > Can you please provide your .config and the dmesg of a bad and a good run? > > Don't bother. I found it. > > It's a merge artifact. So git bisect pointing at the merge commit is > entirely

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 15:40 +0200, Borislav Petkov wrote: > On Mon, Sep 26, 2016 at 02:39:53PM +0200, Mike Galbraith wrote: > > On Mon, 2016-09-26 at 14:29 +0200, Mike Galbraith wrote: > > > > > Checkout timers/core, and merge nodeid, and all is well. I'm > &g

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 15:40 +0200, Borislav Petkov wrote: > On Mon, Sep 26, 2016 at 02:39:53PM +0200, Mike Galbraith wrote: > > On Mon, 2016-09-26 at 14:29 +0200, Mike Galbraith wrote: > > > > > Checkout timers/core, and merge nodeid, and all is well. I'm > &g

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 14:29 +0200, Mike Galbraith wrote: > Checkout timers/core, and merge nodeid, and all is well. I'm currently > bisecting the result against HEAD.. which will likely be about as > useful as the last five bisections, but ya never know. (ok git, finger > some

Re: [x86-tip] strange nr_cpus= boot regression

On Mon, 2016-09-26 at 14:29 +0200, Mike Galbraith wrote: > Checkout timers/core, and merge nodeid, and all is well. I'm currently > bisecting the result against HEAD.. which will likely be about as > useful as the last five bisections, but ya never know. (ok git, finger > some

[x86-tip] strange nr_cpus= boot regression

Hi Ingo, I've encountered a strange regression in tip, symptom is that if you boot with nr_cpus=nr_you_have, what actually boots is nr_you_have/2. Do not pass nr_cpus=, and all is well. Bisection repeatedly goes as below, pointing to the nodeid merge, despite both timers/core and x86/apic

[x86-tip] strange nr_cpus= boot regression

Hi Ingo, I've encountered a strange regression in tip, symptom is that if you boot with nr_cpus=nr_you_have, what actually boots is nr_you_have/2. Do not pass nr_cpus=, and all is well. Bisection repeatedly goes as below, pointing to the nodeid merge, despite both timers/core and x86/apic

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On Sun, 2016-09-25 at 19:21 +0200, Mike Galbraith wrote: > On Sun, 2016-09-25 at 21:40 +0900, Tomasz Chmielewski wrote: > > > The problem is the allocator. > > > > -CONFIG_SLUB=y > > +CONFIG_SLAB=y > > > > > > With SLUB, I'm get

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On Sun, 2016-09-25 at 19:21 +0200, Mike Galbraith wrote: > On Sun, 2016-09-25 at 21:40 +0900, Tomasz Chmielewski wrote: > > > The problem is the allocator. > > > > -CONFIG_SLUB=y > > +CONFIG_SLAB=y > > > > > > With SLUB, I'm get

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On Sun, 2016-09-25 at 21:40 +0900, Tomasz Chmielewski wrote: > The problem is the allocator. > > -CONFIG_SLUB=y > +CONFIG_SLAB=y > > > With SLUB, I'm getting a handful of kworker processes, as expected. > > With SLAB, I'm getting thousands of kworker processes. > > > Not sure if that's

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On Sun, 2016-09-25 at 21:40 +0900, Tomasz Chmielewski wrote: > The problem is the allocator. > > -CONFIG_SLUB=y > +CONFIG_SLAB=y > > > With SLUB, I'm getting a handful of kworker processes, as expected. > > With SLAB, I'm getting thousands of kworker processes. > > > Not sure if that's

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On Fri, 2016-09-23 at 22:23 +0900, Tomasz Chmielewski wrote: > On 2016-09-19 16:08, Tomasz Chmielewski wrote: > > On several servers running 4.7.x and 4.8-rc6/7 kernels I'm seeing > > thousands of kworker processes. > > # ps auxf|grep -c kworker > > 2104 > > Load average goes into hundreds on a

Re: thousands of kworker processes with 4.7.x and 4.8-rc*

On Fri, 2016-09-23 at 22:23 +0900, Tomasz Chmielewski wrote: > On 2016-09-19 16:08, Tomasz Chmielewski wrote: > > On several servers running 4.7.x and 4.8-rc6/7 kernels I'm seeing > > thousands of kworker processes. > > # ps auxf|grep -c kworker > > 2104 > > Load average goes into hundreds on a

Re: [RFC][PATCH] dm: Remove dm_bufio_cond_resched()

On Fri, 2016-09-23 at 14:26 +0200, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 02:17:10PM +0200, Mike Galbraith wrote: > > On Fri, 2016-09-23 at 10:00 +0200, Thomas Gleixner wrote: > > > On Fri, 23 Sep 2016, Peter Zijlstra wrote: > > > > > > Is anybody stil

Re: [RFC][PATCH] dm: Remove dm_bufio_cond_resched()

On Fri, 2016-09-23 at 14:26 +0200, Peter Zijlstra wrote: > On Fri, Sep 23, 2016 at 02:17:10PM +0200, Mike Galbraith wrote: > > On Fri, 2016-09-23 at 10:00 +0200, Thomas Gleixner wrote: > > > On Fri, 23 Sep 2016, Peter Zijlstra wrote: > > > > > > Is anybody stil

Re: [RFC][PATCH] dm: Remove dm_bufio_cond_resched()

On Fri, 2016-09-23 at 10:00 +0200, Thomas Gleixner wrote: > On Fri, 23 Sep 2016, Peter Zijlstra wrote: > > Is anybody still using PREEMPT_NONE? Most workloads also care about > > latency to some extend. Lots of code has explicit cond_resched() and > > doesn't worry. > > Dunno. But I bet there

Re: [RFC][PATCH] dm: Remove dm_bufio_cond_resched()

On Fri, 2016-09-23 at 10:00 +0200, Thomas Gleixner wrote: > On Fri, 23 Sep 2016, Peter Zijlstra wrote: > > Is anybody still using PREEMPT_NONE? Most workloads also care about > > latency to some extend. Lots of code has explicit cond_resched() and > > doesn't worry. > > Dunno. But I bet there

Re: strace lockup when tracing exec in go

On Thu, 2016-09-22 at 11:53 +0200, Michal Hocko wrote: > On Thu 22-09-16 11:40:09, Mike Galbraith wrote: > > This patch doesn't help, nor does the previous patch... but with both > > applied, all is well. All you have to do now is figure out why :) > > Ohh, I should be more

Re: strace lockup when tracing exec in go

On Thu, 2016-09-22 at 11:53 +0200, Michal Hocko wrote: > On Thu 22-09-16 11:40:09, Mike Galbraith wrote: > > This patch doesn't help, nor does the previous patch... but with both > > applied, all is well. All you have to do now is figure out why :) > > Ohh, I should be more

Re: strace lockup when tracing exec in go

On Thu, 2016-09-22 at 10:36 +0200, Michal Hocko wrote: > On Thu 22-09-16 10:01:26, Michal Hocko wrote: > > On Thu 22-09-16 06:15:02, Mike Galbraith wrote: > > [...] > > > master.today... > > > > Thanks for trying to reproduce this. My tiny laptop (2 cores, 2 th

Re: strace lockup when tracing exec in go

On Thu, 2016-09-22 at 10:36 +0200, Michal Hocko wrote: > On Thu 22-09-16 10:01:26, Michal Hocko wrote: > > On Thu 22-09-16 06:15:02, Mike Galbraith wrote: > > [...] > > > master.today... > > > > Thanks for trying to reproduce this. My tiny laptop (2 cores, 2 th

Re: strace lockup when tracing exec in go

On Wed, 2016-09-21 at 17:29 +0200, Michal Hocko wrote: > [I am CCing strace mailing list because even if this turns out to be a > kernel bug strace seems to be doing something unexpected - more on that > below] > > Hi, > Aleksa has reported the following lockup when stracing the following go >

Re: strace lockup when tracing exec in go

On Wed, 2016-09-21 at 17:29 +0200, Michal Hocko wrote: > [I am CCing strace mailing list because even if this turns out to be a > kernel bug strace seems to be doing something unexpected - more on that > below] > > Hi, > Aleksa has reported the following lockup when stracing the following go >

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote: > This patch introduces a new futex implementation called > throughput-optimized (TO) futexes. nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as shorthand for timeout in the next patch. > /* > ->>

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote: > This patch introduces a new futex implementation called > throughput-optimized (TO) futexes. nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as shorthand for timeout in the next patch. > /* > ->>

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Sat, 2016-09-17 at 20:58 +0100, Matt Fleming wrote: > These addresses are pretty low. Can you try the hacky patch plus > Ricardo's change in commit 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init > until after memblock_x86_fill"). He fixed a bug where it's possible to > run out of memblock

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Sat, 2016-09-17 at 20:58 +0100, Matt Fleming wrote: > These addresses are pretty low. Can you try the hacky patch plus > Ricardo's change in commit 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init > until after memblock_x86_fill"). He fixed a bug where it's possible to > run out of memblock

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Fri, 2016-09-16 at 15:45 +0100, Mark Rutland wrote: > > diff --git a/arch/x86/platform/efi/quirks.c > > b/arch/x86/platform/efi/quirks.c > > index f14b7a9da24b..e881b4b2ffd6 100644 > > --- a/arch/x86/platform/efi/quirks.c > > +++ b/arch/x86/platform/efi/quirks.c > > @@ -201,8 +201,10 @@ void

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Fri, 2016-09-16 at 15:45 +0100, Mark Rutland wrote: > > diff --git a/arch/x86/platform/efi/quirks.c > > b/arch/x86/platform/efi/quirks.c > > index f14b7a9da24b..e881b4b2ffd6 100644 > > --- a/arch/x86/platform/efi/quirks.c > > +++ b/arch/x86/platform/efi/quirks.c > > @@ -201,8 +201,10 @@ void

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Fri, 2016-09-16 at 15:30 +0100, Matt Fleming wrote: > On Fri, 16 Sep, at 12:00:59PM, Mike Galbraith wrote: > > > > Ok, here's the whole thing just in case. Hope it's not too big. > > [...] > > > [0.00] esrt: Reserving ESRT space from 0xdef87

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Fri, 2016-09-16 at 15:30 +0100, Matt Fleming wrote: > On Fri, 16 Sep, at 12:00:59PM, Mike Galbraith wrote: > > > > Ok, here's the whole thing just in case. Hope it's not too big. > > [...] > > > [0.00] esrt: Reserving ESRT space from 0xdef87

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Fri, 2016-09-16 at 10:31 +0100, Matt Fleming wrote: > On Fri, 16 Sep, at 08:05:12AM, Mike Galbraith wrote: > > Hi Matt, > > > > My workstation started instant rebooting with tip. I bisected it to.. > > > >efi/esrt: Use efi_mem_reserve() and avoid a km

Re: [tip regression] efi: Allow drivers to reserve boot services forever == toxic

On Fri, 2016-09-16 at 10:31 +0100, Matt Fleming wrote: > On Fri, 16 Sep, at 08:05:12AM, Mike Galbraith wrote: > > Hi Matt, > > > > My workstation started instant rebooting with tip. I bisected it to.. > > > >efi/esrt: Use efi_mem_reserve() and avoid a km

[tip regression] efi: Allow drivers to reserve boot services forever == toxic

Hi Matt, My workstation started instant rebooting with tip. I bisected it to.. efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() ..but seems it's really $subject, as box works fine with the below. --- drivers/firmware/efi/efi.c |1 + 1 file changed, 1 insertion(+) ---

[tip regression] efi: Allow drivers to reserve boot services forever == toxic

Hi Matt, My workstation started instant rebooting with tip. I bisected it to.. efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() ..but seems it's really $subject, as box works fine with the below. --- drivers/firmware/efi/efi.c |1 + 1 file changed, 1 insertion(+) ---

Re: rcu_sched self-detected stall on CPU

On Wed, 2016-09-14 at 23:02 -0500, NTU wrote: > [ 26.542980] Call Trace: > [ 26.542983] [] ? 0xa7fbd7c1 > [ 26.542985] [] ? 0xa7f17d35 > [ 26.542986] [] ? 0xa796c115 > [ 26.542988] [] ? 0xa7633d86 > [ 26.542989] [] ? 0xa796c0a6 ... The

Re: rcu_sched self-detected stall on CPU

On Wed, 2016-09-14 at 23:02 -0500, NTU wrote: > [ 26.542980] Call Trace: > [ 26.542983] [] ? 0xa7fbd7c1 > [ 26.542985] [] ? 0xa7f17d35 > [ 26.542986] [] ? 0xa796c115 > [ 26.542988] [] ? 0xa7633d86 > [ 26.542989] [] ? 0xa796c0a6 ... The

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > > > As for your example, who performs the cgroup setup and configuration, > > > the application itself or an external entity? If an external entity, > > > how does it know which thread is what? > > > > In my case, it would be a little script

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > > > As for your example, who performs the cgroup setup and configuration, > > > the application itself or an external entity? If an external entity, > > > how does it know which thread is what? > > > > In my case, it would be a little script

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > But, whatever, let's go there: Given the arguments that I laid out for > the no-internal-tasks rule, how does the problem seem fixable through > relaxing the constraint? Well, for one thing, cpusets would cease to leak CPUs. With the no

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote: > But, whatever, let's go there: Given the arguments that I laid out for > the no-internal-tasks rule, how does the problem seem fixable through > relaxing the constraint? Well, for one thing, cpusets would cease to leak CPUs. With the no

Re: [ANNOUNCE] 4.8-rc5-rt1 beta

On Tue, 2016-09-06 at 14:25 -0400, Paul Gortmaker wrote: > Patch conflicts/issues of interest 4.6 --> 4.7 > -- > > -v4.7 introduced a lot of users of down_write_killable which wasn't > implemented for -rt (rwsem_rt.h), so I created one. (see new

Re: [ANNOUNCE] 4.8-rc5-rt1 beta

On Tue, 2016-09-06 at 14:25 -0400, Paul Gortmaker wrote: > Patch conflicts/issues of interest 4.6 --> 4.7 > -- > > -v4.7 introduced a lot of users of down_write_killable which wasn't > implemented for -rt (rwsem_rt.h), so I created one. (see new

Re: [v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Tue, 2016-09-06 at 15:42 +0200, Vincent Guittot wrote: > On 6 September 2016 at 15:07, Mike Galbraith <umgwanakikb...@gmail.com> wrote: > > On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote: > > > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écr

Re: [v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Tue, 2016-09-06 at 15:42 +0200, Vincent Guittot wrote: > On 6 September 2016 at 15:07, Mike Galbraith wrote: > > On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote: > > > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écrit : > > > >

Re: [v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Tue, 2016-09-06 at 15:07 +0200, Mike Galbraith wrote: > On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote: > > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écrit : > > > Coming back to this, how about this instead, only increase the > > > grou

Re: [v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Tue, 2016-09-06 at 15:07 +0200, Mike Galbraith wrote: > On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote: > > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écrit : > > > Coming back to this, how about this instead, only increase the > > > grou

Re: [v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote: > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écrit : > > Coming back to this, how about this instead, only increase the group > > imbalance threshold when sd_llc_size == 2. Newer L3 equipped > > p

Re: [v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Tue, 2016-09-06 at 15:01 +0200, Vincent Guittot wrote: > Le Monday 05 Sep 2016 à 18:26:53 (+0200), Mike Galbraith a écrit : > > Coming back to this, how about this instead, only increase the group > > imbalance threshold when sd_llc_size == 2. Newer L3 equipped > > p

Re: [PATCH 0/7] perpcu rwsem, fs/locks and killing lglocks

On Mon, 2016-09-05 at 21:40 +0200, Peter Zijlstra wrote: > Hi all, > > Here are some patches that I've been sitting on for far too long now. Woohoo, goodbye to bad rubbish. FWIW, I plugged these into 4.8-rt (motto: if it's gonna go boom anywhere, it'll likely do so in rt), and am beating the

Re: [PATCH 0/7] perpcu rwsem, fs/locks and killing lglocks

On Mon, 2016-09-05 at 21:40 +0200, Peter Zijlstra wrote: > Hi all, > > Here are some patches that I've been sitting on for far too long now. Woohoo, goodbye to bad rubbish. FWIW, I plugged these into 4.8-rt (motto: if it's gonna go boom anywhere, it'll likely do so in rt), and am beating the

[v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

-by: Mike Galbraith <mgalbra...@suse.de> Fixes: caeb178c sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd Cc: <sta...@vger.kernel.org> # v3.18+ --- kernel/sched/fair.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) --- a/kernel/sched/

[v2 patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

-by: Mike Galbraith Fixes: caeb178c sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd Cc: # v3.18+ --- kernel/sched/fair.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7249,12 +7249,19

Re: [RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

On Mon, 2016-09-05 at 09:48 +0200, Peter Zijlstra wrote: > On Mon, Sep 05, 2016 at 05:14:19PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2016-09-05 at 13:16 +1000, Balbir Singh wrote: > > > > .../... > > > > > > Cc: Peter Zijlstra > > > Cc: Nicholas Piggin

Re: [RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

On Mon, 2016-09-05 at 09:48 +0200, Peter Zijlstra wrote: > On Mon, Sep 05, 2016 at 05:14:19PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2016-09-05 at 13:16 +1000, Balbir Singh wrote: > > > > .../... > > > > > > Cc: Peter Zijlstra > > > Cc: Nicholas Piggin > > > > Acked-by: Benjamin

[oops] [tip:x86/apic] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Thu, 2016-08-18 at 04:02 -0700, tip-bot for Rui Wang wrote: > Commit-ID: 584c5c422f6c749ced1e0bc3c6837f650f64e1e1 > Gitweb: > http://git.kernel.org/tip/584c5c422f6c749ced1e0bc3c6837f650f64e1e1 > Author: Rui Wang > AuthorDate: Wed, 17 Aug 2016 16:00:34 +0800 >

[oops] [tip:x86/apic] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Thu, 2016-08-18 at 04:02 -0700, tip-bot for Rui Wang wrote: > Commit-ID: 584c5c422f6c749ced1e0bc3c6837f650f64e1e1 > Gitweb: > http://git.kernel.org/tip/584c5c422f6c749ced1e0bc3c6837f650f64e1e1 > Author: Rui Wang > AuthorDate: Wed, 17 Aug 2016 16:00:34 +0800 > Committer: Ingo Molnar

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Thu, 2016-09-01 at 06:11 +0200, Mike Galbraith wrote: > I don't see a great alternative to turning it off off the top of my > head, at least for processors with multiple LLCs. Here of course I mean other than saying it's just not worth worrying about such old processors, iff it's on

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Thu, 2016-09-01 at 06:11 +0200, Mike Galbraith wrote: > I don't see a great alternative to turning it off off the top of my > head, at least for processors with multiple LLCs. Here of course I mean other than saying it's just not worth worrying about such old processors, iff it's on

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Wed, 2016-08-31 at 17:52 +0200, Vincent Guittot wrote: > On 31 August 2016 at 12:36, Mike Galbraith <umgwanakikb...@gmail.com> wrote: > > On Wed, 2016-08-31 at 12:18 +0200, Mike Galbraith wrote: > > > On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote: > > &

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Wed, 2016-08-31 at 17:52 +0200, Vincent Guittot wrote: > On 31 August 2016 at 12:36, Mike Galbraith wrote: > > On Wed, 2016-08-31 at 12:18 +0200, Mike Galbraith wrote: > > > On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote: > > > > > > So 43

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Wed, 2016-08-31 at 12:18 +0200, Mike Galbraith wrote: > On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote: > > So 43f4d66637bc ("sched: Improve sysbench performance by fixing spurious > > active migration") 's +1 made sense in that its a tie breaker. If you >

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Wed, 2016-08-31 at 12:18 +0200, Mike Galbraith wrote: > On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote: > > So 43f4d66637bc ("sched: Improve sysbench performance by fixing spurious > > active migration") 's +1 made sense in that its a tie breaker. If you >

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote: > On Tue, Aug 30, 2016 at 07:42:55AM +0200, Mike Galbraith wrote: > > > > 43f4d666 partially cured spurious migrations, but when there are > > completely idle groups on a lightly loaded processor, and there is >

Re: [patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote: > On Tue, Aug 30, 2016 at 07:42:55AM +0200, Mike Galbraith wrote: > > > > 43f4d666 partially cured spurious migrations, but when there are > > completely idle groups on a lightly loaded processor, and there is >

[patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

-by: Mike Galbraith <mgalbra...@suse.de> Fixes: caeb178c sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd Cc: <sta...@vger.kernel.org> # v3.18+ --- kernel/sched/fair.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/kernel/sched/fair.c +++ b/

[patch v3.18+ regression fix] sched: Further improve spurious CPU_IDLE active migrations

-by: Mike Galbraith Fixes: caeb178c sched/fair: Make update_sd_pick_busiest() return 'true' on a busier sd Cc: # v3.18+ --- kernel/sched/fair.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7249,11 +7249,12 @@ static struct

Re: [Documentation] State of CPU controller in cgroup v2

On Sat, 2016-08-20 at 11:56 -0400, Tejun Heo wrote: > > > there are other reasons to enforce process granularity. One > > > important one is isolating system-level management operations from > > > in-process application operations. The cgroup interface, being a > > > virtual filesystem,

Re: [Documentation] State of CPU controller in cgroup v2

On Sat, 2016-08-20 at 11:56 -0400, Tejun Heo wrote: > > > there are other reasons to enforce process granularity. One > > > important one is isolating system-level management operations from > > > in-process application operations. The cgroup interface, being a > > > virtual filesystem,

why is CONFIG_FRAME_POINTER=y so expensive?

Greetings, tbench 8 throughput on my i4790 box: 123 avg master 3769.95 3759.28 3762.83 3764.02 1.000 master-framepointer 3476.73 3453.52 3460.62 3463.62 .920 Does anyone know why the performance impact is this

why is CONFIG_FRAME_POINTER=y so expensive?

Greetings, tbench 8 throughput on my i4790 box: 123 avg master 3769.95 3759.28 3762.83 3764.02 1.000 master-framepointer 3476.73 3453.52 3460.62 3463.62 .920 Does anyone know why the performance impact is this

Re: [Documentation] State of CPU controller in cgroup v2

On Tue, 2016-08-16 at 12:30 -0400, Johannes Weiner wrote: > On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote: > > Also, the argument there seems unfair at best, you don't need cpu-v2 for > > buffered write control, you only need memcg and block co-mounted. > > Yes, memcg and block

Re: [Documentation] State of CPU controller in cgroup v2

On Tue, 2016-08-16 at 12:30 -0400, Johannes Weiner wrote: > On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote: > > Also, the argument there seems unfair at best, you don't need cpu-v2 for > > buffered write control, you only need memcg and block co-mounted. > > Yes, memcg and block

Re: [patch] sched/cputime: Fix NO_HZ_FULL getrusage() monotonicity regression

On Mon, 2016-08-15 at 10:51 +0200, Peter Zijlstra wrote: > On Wed, Aug 10, 2016 at 08:57:28PM +0200, Mike Galbraith wrote: > > > > +> >> > /* > > +> >> > * sum_exec_runtime has moved, but nothing has yet been > > +>

Re: [patch] sched/cputime: Fix NO_HZ_FULL getrusage() monotonicity regression

On Mon, 2016-08-15 at 10:51 +0200, Peter Zijlstra wrote: > On Wed, Aug 10, 2016 at 08:57:28PM +0200, Mike Galbraith wrote: > > > > +> >> > /* > > +> >> > * sum_exec_runtime has moved, but nothing has yet been > > +>

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-08-12 at 18:17 -0400, Johannes Weiner wrote: > > > This argument that cgroup2 is not backward compatible is laughable. > > > > Fine, you're entitled to your sense of humor. I have one to, I find it > > laughable that threaded applications can only sit there like a lump of > > mud

Re: [Documentation] State of CPU controller in cgroup v2

On Fri, 2016-08-12 at 18:17 -0400, Johannes Weiner wrote: > > > This argument that cgroup2 is not backward compatible is laughable. > > > > Fine, you're entitled to your sense of humor. I have one to, I find it > > laughable that threaded applications can only sit there like a lump of > > mud

<    10   11   12   13   14   15   16   17   18   19   >