Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Hi Steve, On Tue, Dec 15, 2015 at 01:56:01PM -0800, Steve Muckle wrote: > On 12/14/2015 06:22 PM, Yuyang Du wrote: > > what if we just init the util_avg to 0? > > With scheduler-guided frequency [1] we will rely on the initial util_avg > value to determine the CPU frequency response when new

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Hi Steve, On Tue, Dec 15, 2015 at 01:56:01PM -0800, Steve Muckle wrote: > On 12/14/2015 06:22 PM, Yuyang Du wrote: > > what if we just init the util_avg to 0? > > With scheduler-guided frequency [1] we will rely on the initial util_avg > value to determine the CPU frequency response when new

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On 12/14/2015 06:22 PM, Yuyang Du wrote: > what if we just init the util_avg to 0? With scheduler-guided frequency [1] we will rely on the initial util_avg value to determine the CPU frequency response when new tasks are created. There is sure to be a lot of debate on what sort of default policy

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 12:54:53PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2015 at 06:42:24AM +0800, Yuyang Du wrote: > > > In most cases 'r' shouldn't exceed 1024 and util_sum not significantly > > > exceed 1024*47742, but in extreme cases like spawning lots of new tasks > > > it may

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 12:54:53PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2015 at 06:42:24AM +0800, Yuyang Du wrote: > > > In most cases 'r' shouldn't exceed 1024 and util_sum not significantly > > > exceed 1024*47742, but in extreme cases like spawning lots of new tasks > > > it may

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On 12/14/2015 06:22 PM, Yuyang Du wrote: > what if we just init the util_avg to 0? With scheduler-guided frequency [1] we will rely on the initial util_avg value to determine the CPU frequency response when new tasks are created. There is sure to be a lot of debate on what sort of default policy

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Morten Rasmussen writes: > On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: >> So uh yeah, my initial impression is "rip it out", but if being >> immediately-correct is important in the case of one task being most of >> the utilization, rather than when it is more evenly

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 03:20:21PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2015 at 01:07:26PM +, Morten Rasmussen wrote: > > > Agreed, >100% is a transient state (which can be rather long) which only > > means over-utilized, nothing more. Would you like the metric itself to > > be

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 01:07:26PM +, Morten Rasmussen wrote: > Agreed, >100% is a transient state (which can be rather long) which only > means over-utilized, nothing more. Would you like the metric itself to > be changed to saturate at 100% or just cap it to 100% when used? We already cap

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 12:54:53PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2015 at 06:42:24AM +0800, Yuyang Du wrote: > > > In most cases 'r' shouldn't exceed 1024 and util_sum not significantly > > > exceed 1024*47742, but in extreme cases like spawning lots of new tasks > > > it may

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: > Dietmar Eggemann writes: > > IMHO, on 32bit machine we can deal with (2147483648/47742/1024 = 43.9) > > 43 tasks before overflowing. > > > > Can we have a scenario where >43 tasks with se->avg.util_avg=1024 value > > get

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 06:42:24AM +0800, Yuyang Du wrote: > > In most cases 'r' shouldn't exceed 1024 and util_sum not significantly > > exceed 1024*47742, but in extreme cases like spawning lots of new tasks > > it may potentially overflow 32 bit. Newly created tasks contribute > > 1024*47742

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: > Dietmar Eggemann writes: > > IMHO, on 32bit machine we can deal with (2147483648/47742/1024 = 43.9) > > 43 tasks before overflowing. > > > > Can we have a scenario where >43 tasks with

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 06:42:24AM +0800, Yuyang Du wrote: > > In most cases 'r' shouldn't exceed 1024 and util_sum not significantly > > exceed 1024*47742, but in extreme cases like spawning lots of new tasks > > it may potentially overflow 32 bit. Newly created tasks contribute > > 1024*47742

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 12:54:53PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2015 at 06:42:24AM +0800, Yuyang Du wrote: > > > In most cases 'r' shouldn't exceed 1024 and util_sum not significantly > > > exceed 1024*47742, but in extreme cases like spawning lots of new tasks > > > it may

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 01:07:26PM +, Morten Rasmussen wrote: > Agreed, >100% is a transient state (which can be rather long) which only > means over-utilized, nothing more. Would you like the metric itself to > be changed to saturate at 100% or just cap it to 100% when used? We already cap

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Mon, Dec 14, 2015 at 03:20:21PM +0100, Peter Zijlstra wrote: > On Mon, Dec 14, 2015 at 01:07:26PM +, Morten Rasmussen wrote: > > > Agreed, >100% is a transient state (which can be rather long) which only > > means over-utilized, nothing more. Would you like the metric itself to > > be

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Morten Rasmussen writes: > On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: >> So uh yeah, my initial impression is "rip it out", but if being >> immediately-correct is important in the case of one task being most of >> the utilization, rather than

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 05:57:51PM +, Morten Rasmussen wrote: > > >>> if (atomic_long_read(_rq->removed_load_avg)) { > > >>> - long r = atomic_long_xchg(_rq->removed_load_avg, 0); > > >>> + s64 r = atomic_long_xchg(_rq->removed_load_avg, 0); > > >>>

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: > First, I believe in theory util_avg on a cpu should add up to 100% or > 1024 or whatever. However, recently migrated-in tasks don't have their > utilization cleared, so if they were quickly migrated again you could > have up to

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 11:18:56AM -0800, bseg...@google.com wrote: > First, I believe in theory util_avg on a cpu should add up to 100% or > 1024 or whatever. However, recently migrated-in tasks don't have their > utilization cleared, so if they were quickly migrated again you could > have up to

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 05:57:51PM +, Morten Rasmussen wrote: > > >>> if (atomic_long_read(_rq->removed_load_avg)) { > > >>> - long r = atomic_long_xchg(_rq->removed_load_avg, 0); > > >>> + s64 r = atomic_long_xchg(_rq->removed_load_avg, 0); > > >>>

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Dietmar Eggemann writes: > On 11/12/15 17:57, Morten Rasmussen wrote: >> On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: >>> >>> >>> On 12/11/2015 04:36 PM, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On 11/12/15 17:57, Morten Rasmussen wrote: > On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: >> >> >> On 12/11/2015 04:36 PM, Peter Zijlstra wrote: >>> On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: > > > On 12/11/2015 04:36 PM, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: > >> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: > >>> Make 'r' 64-bit type to avoid

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Andrey Ryabinin writes: > On 12/11/2015 04:36 PM, Peter Zijlstra wrote: >> On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >>> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' on 32-bit

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On 12/11/2015 04:36 PM, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: >>> Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' >>> on 32-bit systems: >>> UBSAN: Undefined

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: > > Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' > > on 32-bit systems: > > UBSAN: Undefined behaviour in kernel/sched/fair.c:2785:18 > >

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: > Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' > on 32-bit systems: > UBSAN: Undefined behaviour in kernel/sched/fair.c:2785:18 > signed integer overflow: > 87950 * 47742 cannot be represented in

[PATCH] sched/fair: fix mul overflow on 32-bit systems

Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' on 32-bit systems: UBSAN: Undefined behaviour in kernel/sched/fair.c:2785:18 signed integer overflow: 87950 * 47742 cannot be represented in type 'int' Fixes: 9d89c257dfb9 ("sched/fair: Rewrite runnable load and

[PATCH] sched/fair: fix mul overflow on 32-bit systems

Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' on 32-bit systems: UBSAN: Undefined behaviour in kernel/sched/fair.c:2785:18 signed integer overflow: 87950 * 47742 cannot be represented in type 'int' Fixes: 9d89c257dfb9 ("sched/fair: Rewrite runnable load and

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: > > Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' > > on 32-bit systems: > > UBSAN: Undefined behaviour in kernel/sched/fair.c:2785:18 > >

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: > Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' > on 32-bit systems: > UBSAN: Undefined behaviour in kernel/sched/fair.c:2785:18 > signed integer overflow: > 87950 * 47742 cannot be represented in

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Andrey Ryabinin writes: > On 12/11/2015 04:36 PM, Peter Zijlstra wrote: >> On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >>> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: Make 'r' 64-bit type to avoid overflow in 'r *

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: > > > On 12/11/2015 04:36 PM, Peter Zijlstra wrote: > > On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: > >> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: > >>> Make 'r' 64-bit type to avoid

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On 12/11/2015 04:36 PM, Peter Zijlstra wrote: > On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >> On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin wrote: >>> Make 'r' 64-bit type to avoid overflow in 'r * LOAD_AVG_MAX' >>> on 32-bit systems: >>> UBSAN: Undefined

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

Dietmar Eggemann writes: > On 11/12/15 17:57, Morten Rasmussen wrote: >> On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: >>> >>> >>> On 12/11/2015 04:36 PM, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: >

Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems

On 11/12/15 17:57, Morten Rasmussen wrote: > On Fri, Dec 11, 2015 at 05:00:01PM +0300, Andrey Ryabinin wrote: >> >> >> On 12/11/2015 04:36 PM, Peter Zijlstra wrote: >>> On Fri, Dec 11, 2015 at 02:25:51PM +0100, Peter Zijlstra wrote: On Fri, Dec 11, 2015 at 03:55:18PM +0300, Andrey Ryabinin