sched: write better comments for weight calculations
PATCH 1/1 sched: write better comments for weight calculations
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
--- kernel/sched/core.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)
kernel/sched/core.c +19 -8
@@ -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. To achieve that, we use a multiplier +* of 1.25. 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: +* +* 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) +* T2's CPU slice = (820 / (820 + 1024)) * 10 ~= 4.5ms (45% usage) */ const int sched_prio_to_weight[40 ] = {/* -20 */ 88761 ,71755 ,56483 ,46273 ,36291 ,
Signature · 1 line
2.12.0.246.ga2ecc84866-goog
Few comments inline, otherwise LGTM.
Cheers Patrick
Quoted 29 lines · Joel Fernandes
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
Cc Juri Lelli <[email protected]>Cc Patrick Bellasi <[email protected]>Cc Dietmar Eggemann <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Ingo Molnar <[email protected]>Signed-off-by Joel Fernandes <[email protected]>--- kernel/sched/core.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)kernel/sched/core.c +4
-4@@ -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
kernel/sched/core.c void dump_cpu_task(int cpu) · line 8835
Quoted 10 lines
kernel/sched/core.c +4
-4+* 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.
^
relativekernel/sched/core.c void dump_cpu_task(int cpu) · line 8836
Quoted 1 line
kernel/sched/core.c +1
-0+* To achieve that, we use a multiplier of 1.25.
The following sentence:
kernel/sched/core.c void dump_cpu_task(int cpu) · line 8838
Quoted 3 lines
kernel/sched/core.c +3
-0+* 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.
kernel/sched/core.c void dump_cpu_task(int cpu) · line 8845
Quoted 7 lines
kernel/sched/core.c +7
-0+* +* 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)
^
mskernel/sched/core.c void dump_cpu_task(int cpu) · line 8846
Quoted 1 line
kernel/sched/core.c +1
-0+* T2's CPU slice = (820 / (820 + 1024)) * 10 ~= 4.5ms (45% usage)
^
msQuoted 6 lines
kernel/sched/core.c +0
-0*/ const int sched_prio_to_weight[40 ] = {/* -20 */ 88761 ,71755 ,56483 ,46273 ,36291 ,Signature · 1 line
2.12.0.246.ga2ecc84866-goog
Signature · 3 lines
#include <best/regards.h> Patrick Bellasi
Quoted 1 line · Patrick Bellasi
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.
Quoted 52 lines · Joel Fernandes
Quoted 29 lines
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
Cc Juri Lelli <[email protected]>Cc Patrick Bellasi <[email protected]>Cc Dietmar Eggemann <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Ingo Molnar <[email protected]>Signed-off-by Joel Fernandes <[email protected]>--- kernel/sched/core.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)kernel/sched/core.c +4
-4@@ -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 kernel/sched/core.c void dump_cpu_task(int cpu) · line 8835
Quoted 10 lines
kernel/sched/core.c +4
-4+* 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. ^ relativekernel/sched/core.c void dump_cpu_task(int cpu) · line 8836
Quoted 1 line
kernel/sched/core.c +1
-0+* To achieve that, we use a multiplier of 1.25. The following sentence:
kernel/sched/core.c void dump_cpu_task(int cpu) · line 8838
Quoted 3 lines
kernel/sched/core.c +3
-0+* 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:
Quoted 8 lines
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.
Quoted 6 lines · Joel Fernandes
Quoted 1 line · Patrick Bellasi
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
Quoted 64 lines
Quoted 52 lines · Joel Fernandes
Quoted 29 lines
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
Cc Juri Lelli <[email protected]>Cc Patrick Bellasi <[email protected]>Cc Dietmar Eggemann <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Ingo Molnar <[email protected]>Signed-off-by Joel Fernandes <[email protected]>--- kernel/sched/core.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-)kernel/sched/core.c +4
-4@@ -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 kernel/sched/core.c void dump_cpu_task(int cpu) · line 8835
Quoted 10 lines
kernel/sched/core.c +4
-4+* 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. ^ relativekernel/sched/core.c void dump_cpu_task(int cpu) · line 8836
Quoted 1 line
kernel/sched/core.c +1
-0+* To achieve that, we use a multiplier of 1.25. The following sentence:
kernel/sched/core.c void dump_cpu_task(int cpu) · line 8838
Quoted 3 lines
kernel/sched/core.c +3
-0+* 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: Quoted 8 lines
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.
Signature · 3 lines
#include <best/regards.h> Patrick Bellasi
Quoted 5 lines · Patrick Bellasi
Quoted 4 lines · Joel Fernandes
Quoted 1 line · Patrick Bellasi
Few comments inline, otherwise LGTM.
Quoted 7 lines
Quoted 2 lines
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.
Oh, ok. That works :-) Thanks!
Peter Zijlstra
maintainerQuoted 2 lines · Joel Fernandes
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
To what purpose? Bigger word count?
Quoted 5 lines · Peter Zijlstra
Quoted 2 lines · Joel Fernandes
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
To what purpose? Bigger word count?
The intention is to improve the comments to make it more understandable (the weight calculations, factor of 1.25 etc).
On reading through the comments the first time, I felt they could be improved. Is your concern more about the addition of an example increasing the word-count? Perhaps you'd rather this be added to Documentation/ instead?
Regards,
Joel
Peter Zijlstra
maintainerQuoted 7 lines · Joel Fernandes
Quoted 5 lines · Peter Zijlstra
Quoted 2 lines · Joel Fernandes
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
To what purpose? Bigger word count?
Quoted 7 lines
The intention is to improve the comments to make it more understandable (the weight calculations, factor of 1.25 etc).
On reading through the comments the first time, I felt they could be improved. Is your concern more about the addition of an example increasing the word-count? Perhaps you'd rather this be added to
Documentation/instead?
It might just be verbiage; I sometimes have trouble condensing text. That is; some people need repetition, I get stuck trying to figure out if its saying the same or not.
In any case; if you want to clarify where the 1.25 comes from, maybe do an abstract example, instead of an explicit one?
-10% = .9, +10% = 1.1 -> 1.1/.9 = 1.(2) ~ 1.25
Or, starting with the weight thing:
.45 = wa / (wa+wb) -> .45 (wa+wb) = wa ->
.45wa + .45wb = wa -> .45wb = .55wa -> wb/wa = .55/.45 = 1.(2) ~ 1.25
That's actually simpler to follow no?
Now IIRC the whole thing is backwards anyway, we started with 1.25 and got the ~10% from there.
Quoted 28 lines · Peter Zijlstra
Quoted 7 lines · Joel Fernandes
Quoted 5 lines · Peter Zijlstra
Quoted 2 lines · Joel Fernandes
This patch rewrites comments related task priorities and CPU usage along with an example to show how it works.
To what purpose? Bigger word count?
Quoted 7 lines
The intention is to improve the comments to make it more understandable (the weight calculations, factor of 1.25 etc).
On reading through the comments the first time, I felt they could be improved. Is your concern more about the addition of an example increasing the word-count? Perhaps you'd rather this be added to
Documentation/instead?It might just be verbiage; I sometimes have trouble condensing text. That is; some people need repetition, I get stuck trying to figure out if its saying the same or not.
In any case; if you want to clarify where the 1.25 comes from, maybe do an abstract example, instead of an explicit one?
-10% = .9, +10% = 1.1 -> 1.1/.9 = 1.(2) ~ 1.25
Or, starting with the weight thing:
.45 = wa / (wa+wb) -> .45 (wa+wb) = wa ->
Quoted 8 lines
.45wa + .45wb = wa -> .45wb = .55wa -> wb/wa = .55/.45 = 1.(2) ~ 1.25That's actually simpler to follow no?
Now IIRC the whole thing is backwards anyway, we started with 1.25 and got the ~10% from there.
Yes we could condense it further and explain it without using an explicit example. I will work on a better patch along these lines.
Thanks,
Joel