On 15-Mar 05:35, Joel Fernandes wrote: > On Wed, Mar 15, 2017 at 5:04 AM, Patrick Bellasi > <patrick.bell...@arm.com> 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.
Well, I cannot really ACK anything... you should defenitively ask someone else in CC for such a tag ;-) FWIW, if you like, you can add instead a Reviewed-by tag. 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 <juri.le...@arm.com> > >> Cc: Patrick Bellasi <patrick.bell...@arm.com> > >> Cc: Dietmar Eggemann <dietmar.eggem...@arm.com> > >> Cc: Peter Zijlstra <pet...@infradead.org> > >> Cc: Ingo Molnar <mi...@redhat.com> > >> Signed-off-by: Joel Fernandes <joe...@google.com> > >> --- > >> 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. -- #include <best/regards.h> Patrick Bellasi
