remove interactive credit
PATCH 1/1 remove interactive credit
remove interactive credit
Special casing tasks by interactive credit was helpful for preventing fully cpu bound tasks from easily rising to interactive status.
However it did not select out tasks that had periods of being fully cpu bound and then sleeping while waiting on pipes, signals etc. This led to a more disproportionate share of cpu time.
Backing this out will no longer special case only fully cpu bound tasks, and prevents the variable behaviour that occurs at startup before tasks declare themseleves interactive or not, and speeds up application startup slightly under certain circumstances. It does cost in interactivity slightly as load rises but it is worth it for the fairness gains.
include/linux/sched.h +0 -1
@@ -527,7 +527,6 @@ struct task_struct {prio_array_t *array;unsigned long sleep_avg; -long interactive_credit;unsigned long long timestamp, last_ran;int activated;
kernel/sched.c +12 -33
107 lines not on this page · raw message
Quoted 13 lines · Con Kolivas
remove interactive credit
------------------------------------------------------------------------
Special casing tasks by interactive credit was helpful for preventing fully cpu bound tasks from easily rising to interactive status.
However it did not select out tasks that had periods of being fully cpu bound and then sleeping while waiting on pipes, signals etc. This led to a more disproportionate share of cpu time.
Quoted 8 lines
Backing this out will no longer special case only fully cpu bound tasks, and prevents the variable behaviour that occurs at startup before tasks declare themseleves interactive or not, and speeds up application startup slightly under certain circumstances. It does cost in interactivity slightly as load rises but it is worth it for the fairness gains.
Signed-off-by Con Kolivas <[email protected]>
I'm scared :(
I'm in favour of any attempts to simplify things... but will it be two months or three before this spontaneously explodes for half our userbase?
Andrew's boss so he gets to decide >:)
Quoted 23 lines · Nick Piggin
Quoted 12 lines · Con Kolivas
remove interactive credit
------------------------------------------------------------------------
Special casing tasks by interactive credit was helpful for preventing fully cpu bound tasks from easily rising to interactive status.
However it did not select out tasks that had periods of being fully cpu bound and then sleeping while waiting on pipes, signals etc. This led to a more disproportionate share of cpu time.Quoted 8 lines
Backing this out will no longer special case only fully cpu bound tasks, and prevents the variable behaviour that occurs at startup before tasks declare themseleves interactive or not, and speeds up application startup slightly under certain circumstances. It does cost in interactivity slightly as load rises but it is worth it for the fairness gains.
Signed-off-by Con Kolivas <[email protected]>
Quoted 6 lines
I'm scared :(
I'm in favour of any attempts to simplify things... but will it be two months or three before this spontaneously explodes for half our userbase?
Andrew's boss so he gets to decide >:)
If I read the intent right, this is an example of worst case avoidance, where a little average interactivity is traded for preventing the case where a single misguided process gets most/all of the CPU and performance falls off the edge of the table. As a user I see that as the same line of thought which gave us low-latency patches, to trade a miniscule bit of one thing to avoid something really undesirable.
I suspect there will be people who don't want to make this trade, although it sounds like a good one to me.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Quoted 1 line · Con Kolivas
remove interactive credit
we could try this in -mm, but it obviously needs alot of testing first. Do you have any particular workload in mind where the fairness win due to this revert would/should be significant?
Ingo
Quoted 8 lines · Ingo Molnar
Quoted 1 line · Con Kolivas
remove interactive credit
we could try this in -mm, but it obviously needs alot of testing first. Do you have any particular workload in mind where the fairness win due to this revert would/should be significant?
Since I created this variable in the first place I can say with quite some certainty that the size of the advantage is miniscule. Whereas clearly the design introduces special case mistreatment of only one type of task. It's an addition to the interactivity code I've often looked at and regretted doing.
Con
Quoted 11 lines · Con Kolivas
Quoted 5 lines
Quoted 1 line
remove interactive credit
we could try this in -mm, but it obviously needs alot of testing first. Do you have any particular workload in mind where the fairness win due to this revert would/should be significant?
Since I created this variable in the first place I can say with quite some certainty that the size of the advantage is miniscule. Whereas clearly the design introduces special case mistreatment of only one type of task. It's an addition to the interactivity code I've often looked at and regretted doing.
yeah, i know, it was the only piece of code from your earlier -Oint scheduler-fixup series i almost didnt ack. But now it's in and testing needs to cross at least one stable kernel boundary before it can be taken out again. (unless a patch is an obvious or important fix.)
Ingo
Quoted 15 lines · Ingo Molnar
Quoted 10 lines · Con Kolivas
Quoted 4 lines
Quoted 1 line
remove interactive credit
we could try this in -mm, but it obviously needs alot of testing first. Do you have any particular workload in mind where the fairness win due to this revert would/should be significant?
Since I created this variable in the first place I can say with quite some certainty that the size of the advantage is miniscule. Whereas clearly the design introduces special case mistreatment of only one type of task. It's an addition to the interactivity code I've often looked at and regretted doing.
Quoted 4 lines
yeah, i know, it was the only piece of code from your earlier -Oint scheduler-fixup series i almost didnt ack. But now it's in and testing needs to cross at least one stable kernel boundary before it can be taken out again. (unless a patch is an obvious or important fix.)
I've been extensively testing it at this end and recommend giving it a good -mm run. I'm reasonably sure it's related to some of the disproportionate cpu usage reports we've seen with some of those bash script examples (can't recall the details now so I'll need to chase them up). If I didn't suspect it was an issue I wouldn't be keen to undo something either.
Con
Quoted 11 lines · Con Kolivas
Quoted 4 lines
yeah, i know, it was the only piece of code from your earlier -Oint scheduler-fixup series i almost didnt ack. But now it's in and testing needs to cross at least one stable kernel boundary before it can be taken out again. (unless a patch is an obvious or important fix.)
I've been extensively testing it at this end and recommend giving it a good -mm run. I'm reasonably sure it's related to some of the disproportionate cpu usage reports we've seen with some of those bash script examples (can't recall the details now so I'll need to chase them up). If I didn't suspect it was an issue I wouldn't be keen to undo something either.
i'm too quite positive about the expected effects. -mm testing will tell.
Ingo