On Thu, Aug 27, 2020 at 02:53:31PM +0100, Qais Yousef wrote: > On 08/20/20 11:19, Greg Kroah-Hartman wrote: > > From: Qais Yousef <qais.yousef@xxxxxxx> > > > > [ Upstream commit 46609ce227039fd192e0ecc7d940bed587fd2c78 ] > > > > There is a report that when uclamp is enabled, a netperf UDP test > > regresses compared to a kernel compiled without uclamp. > > > > https://lore.kernel.org/lkml/20200529100806.GA3070@xxxxxxx/ > > > > While investigating the root cause, there were no sign that the uclamp > > code is doing anything particularly expensive but could suffer from bad > > cache behavior under certain circumstances that are yet to be > > understood. > > > > https://lore.kernel.org/lkml/20200616110824.dgkkbyapn3io6wik@e107158-lin/ > > > > To reduce the pressure on the fast path anyway, add a static key that is > > by default will skip executing uclamp logic in the > > enqueue/dequeue_task() fast path until it's needed. > > > > As soon as the user start using util clamp by: > > > > 1. Changing uclamp value of a task with sched_setattr() > > 2. Modifying the default sysctl_sched_util_clamp_{min, max} > > 3. Modifying the default cpu.uclamp.{min, max} value in cgroup > > > > We flip the static key now that the user has opted to use util clamp. > > Effectively re-introducing uclamp logic in the enqueue/dequeue_task() > > fast path. It stays on from that point forward until the next reboot. > > > > This should help minimize the effect of util clamp on workloads that > > don't need it but still allow distros to ship their kernels with uclamp > > compiled in by default. > > > > SCHED_WARN_ON() in uclamp_rq_dec_id() was removed since now we can end > > up with unbalanced call to uclamp_rq_dec_id() if we flip the key while > > a task is running in the rq. Since we know it is harmless we just > > quietly return if we attempt a uclamp_rq_dec_id() when > > rq->uclamp[].bucket[].tasks is 0. > > > > In schedutil, we introduce a new uclamp_is_enabled() helper which takes > > the static key into account to ensure RT boosting behavior is retained. > > > > The following results demonstrates how this helps on 2 Sockets Xeon E5 > > 2x10-Cores system. > > > > nouclamp uclamp uclamp-static-key > > Hmean send-64 162.43 ( 0.00%) 157.84 * -2.82%* 163.39 * 0.59%* > > Hmean send-128 324.71 ( 0.00%) 314.78 * -3.06%* 326.18 * 0.45%* > > Hmean send-256 641.55 ( 0.00%) 628.67 * -2.01%* 648.12 * 1.02%* > > Hmean send-1024 2525.28 ( 0.00%) 2448.26 * -3.05%* 2543.73 * 0.73%* > > Hmean send-2048 4836.14 ( 0.00%) 4712.08 * -2.57%* 4867.69 * 0.65%* > > Hmean send-3312 7540.83 ( 0.00%) 7425.45 * -1.53%* 7621.06 * 1.06%* > > Hmean send-4096 9124.53 ( 0.00%) 8948.82 * -1.93%* 9276.25 * 1.66%* > > Hmean send-8192 15589.67 ( 0.00%) 15486.35 * -0.66%* 15819.98 * 1.48%* > > Hmean send-16384 26386.47 ( 0.00%) 25752.25 * -2.40%* 26773.74 * 1.47%* > > > > The perf diff between nouclamp and uclamp-static-key when uclamp is > > disabled in the fast path: > > > > 8.73% -1.55% [kernel.kallsyms] [k] try_to_wake_up > > 0.07% +0.04% [kernel.kallsyms] [k] deactivate_task > > 0.13% -0.02% [kernel.kallsyms] [k] activate_task > > > > The diff between nouclamp and uclamp-static-key when uclamp is enabled > > in the fast path: > > > > 8.73% -0.72% [kernel.kallsyms] [k] try_to_wake_up > > 0.13% +0.39% [kernel.kallsyms] [k] activate_task > > 0.07% +0.38% [kernel.kallsyms] [k] deactivate_task > > > > Fixes: 69842cba9ace ("sched/uclamp: Add CPU's clamp buckets refcounting") > > Reported-by: Mel Gorman <mgorman@xxxxxxx> > > Signed-off-by: Qais Yousef <qais.yousef@xxxxxxx> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> > > Tested-by: Lukasz Luba <lukasz.luba@xxxxxxx> > > Link: https://lkml.kernel.org/r/20200630112123.12076-3-qais.yousef@xxxxxxx > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> > > --- > > Greg/Peter/Mel > > Should this go to 5.4 too? Not saying it should, but I don't know if distros > could care about potential performance hit that this patch addresses. If you want to provide a backported version of this to 5.4.y, that you have tested that works properly, I will be glad to queue it up. thanks, greg k-h
