Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751979AbdCOMEe (ORCPT ); Wed, 15 Mar 2017 08:04:34 -0400 Received: from foss.arm.com ([217.140.101.70]:46192 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750988AbdCOMEd (ORCPT ); Wed, 15 Mar 2017 08:04:33 -0400 Date: Wed, 15 Mar 2017 12:04:28 +0000 From: Patrick Bellasi To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, Juri Lelli , Dietmar Eggemann , Peter Zijlstra , Ingo Molnar Subject: Re: [PATCH] sched: write better comments for weight calculations Message-ID: <20170315120428.GC18557@e110439-lin> References: <20170310204743.12872-1-joelaf@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170310204743.12872-1-joelaf@google.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3381 Lines: 87 Few comments inline, otherwise LGTM. Cheers Patrick On 10-Mar 12:47, Joel Fernandes wrote: > This patch rewrites comments related task priorities and CPU usage > along with an example to show how it works. > > Cc: Juri Lelli > Cc: Patrick Bellasi > Cc: Dietmar Eggemann > Cc: Peter Zijlstra > Cc: Ingo Molnar > Signed-off-by: Joel Fernandes > --- > kernel/sched/core.c | 27 +++++++++++++++++++-------- > 1 file changed, 19 insertions(+), 8 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index c56fb57f2991..2175bf663f3d 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -8823,16 +8823,27 @@ void dump_cpu_task(int cpu) > } > > /* > - * Nice levels are multiplicative, with a gentle 10% change for every > - * nice level changed. I.e. when a CPU-bound task goes from nice 0 to > - * nice 1, it will get ~10% less CPU time than another CPU-bound task > - * that remained on nice 0. > + * Nice levels are multiplicative, with a gentle 10% relative change > + * for every nice level changed. I.e. if there were 2 CPU-bound tasks > + * of equal nice value and one of them goes from a nice level of 0 to 1 > + * then the task at nice level 1 will get ~5% less CPU time than before > + * the change and the task that remained at nice level 0 will get ~5% > + * more CPU time. > * > * The "10% effect" is relative and cumulative: from _any_ nice level, > - * if you go up 1 level, it's -10% CPU usage, if you go down 1 level > - * it's +10% CPU usage. (to achieve that we use a multiplier of 1.25. > - * If a task goes up by ~10% and another task goes down by ~10% then > - * the relative distance between them is ~25%.) > + * if you go up 1 level, it's -10% relative CPU usage, if you go down > + * by 1 level it's +10% CPU usage. ^ relative > + * To achieve that, we use a multiplier of 1.25. The following sentence: > + * If a task goes up by ~5% and another task goes down by ~5% > + * then the relative distance between their weights is ~25% as shown > + * in the following example: is still confusing to me, mainly because we are mixing the "shares percentage" with the CPU usage percentage. What about this: If two tasks have a 25% relative distance between their weights then they will get a 10% difference in CPU usage as shown in the following example. > + * > + * Consider 2 tasks T1 and T2 which are scheduled within a sched_period > + * of 10ms. Say T1 has a nice value 0 and T2 has a nice value 1, > + * then their corresponding weights are 1024 for T1 and 820 for T2. > + * > + * The relative delta between their weights is ~25% (1.25 * 820 ~= 1024) > + * T1's CPU slice = (1024 / (820 + 1024)) * 10 ~= 5.5ms (55% usage) ^ ms > + * T2's CPU slice = (820 / (820 + 1024)) * 10 ~= 4.5ms (45% usage) ^ ms > */ > const int sched_prio_to_weight[40] = { > /* -20 */ 88761, 71755, 56483, 46273, 36291, > -- > 2.12.0.246.ga2ecc84866-goog > -- #include Patrick Bellasi