Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752398AbdCOMgW (ORCPT ); Wed, 15 Mar 2017 08:36:22 -0400 Received: from mail-ua0-f175.google.com ([209.85.217.175]:33610 "EHLO mail-ua0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbdCOMfa (ORCPT ); Wed, 15 Mar 2017 08:35:30 -0400 MIME-Version: 1.0 In-Reply-To: <20170315120428.GC18557@e110439-lin> References: <20170310204743.12872-1-joelaf@google.com> <20170315120428.GC18557@e110439-lin> From: Joel Fernandes Date: Wed, 15 Mar 2017 05:35:28 -0700 Message-ID: Subject: Re: [PATCH] sched: write better comments for weight calculations To: Patrick Bellasi Cc: LKML , Juri Lelli , Dietmar Eggemann , Peter Zijlstra , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2825 Lines: 71 On Wed, Mar 15, 2017 at 5:04 AM, Patrick Bellasi wrote: > Few comments inline, otherwise LGTM. Ok, I'll take that as an Acked-by with the following comment addressed if that's Ok with you. > > 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. I agree your statement is clearer and I will use it in the repost. J.