Re: sched/fair: Fix fixed point arithmetic width for shares and effective load

[Greg KH <gregkh@linuxfoundation.org>]

On Sat, Jan 07, 2017 at 09:38:36PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Please backport
> commit ab522e33f91799661aad47bebb691f241a9f6bb8
> ('sched/fair: Fix fixed point arithmetic width for shares and effective load')
> to 4.8.

As 4.8-stable is about to go end-of-life on Monday (tomorrow), can't you
just use 4.9 instead?

> It was apparently not backported as of 4.8.16, while it fixes a huge
> performance regression in our tests, see the graphs between 19320.5 and
> 19451.5 on
> 
> http://starpu.gforge.inria.fr/testing/trunk/benchmarks/tasks_size_overhead_total_lws-200.png
> 
> which happened to be using a kernel without this fix.
> 
> FTR, here is the patch again.
> 
> Samuel
> 
> commit ab522e33f91799661aad47bebb691f241a9f6bb8
> Author: Dietmar Eggemann <dietmar.eggemann@arm.com>
> Date:   Mon Aug 22 15:00:41 2016 +0100
> 
>     sched/fair: Fix fixed point arithmetic width for shares and effective load
>     
>     Since commit:
>     
>       2159197d6677 ("sched/core: Enable increased load resolution on 64-bit kernels")
>     
>     we now have two different fixed point units for load:
>     
>     - 'shares' in calc_cfs_shares() has 20 bit fixed point unit on 64-bit
>       kernels. Therefore use scale_load() on MIN_SHARES.
>     
>     - 'wl' in effective_load() has 10 bit fixed point unit. Therefore use
>       scale_load_down() on tg->shares which has 20 bit fixed point unit on
>       64-bit kernels.
>     
>     Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>     Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>     Cc: Linus Torvalds <torvalds@linux-foundation.org>
>     Cc: Mike Galbraith <efault@gmx.de>
>     Cc: Peter Zijlstra <peterz@infradead.org>
>     Cc: Thomas Gleixner <tglx@linutronix.de>
>     Link: http://lkml.kernel.org/r/1471874441-24701-1-git-send-email-dietmar.eggemann@arm.com
>     Signed-off-by: Ingo Molnar <mingo@kernel.org>

I would need an ack from the developers of the patch before I could take
this into a stable kernel, but again, it's a bit late for 4.8, so I
don't think we should worry about it anymore, do you?

thanks,

greg k-h