O(1) scheduler, -G1, 2.5.2-pre10, 2.4.17 (fwd)
A message that is not in the archive (sent off-list or not yet received): 1010814327.2018.5.camel@phantasy
Quoted 15 lines · Robert Love
Quoted 3 lines · Timothy Covell
But, given the above case, what happens when you have Sendmail on the first CPU and Squid is sharing the second CPU? This is not optimal either, or am I missing something?
Correct. I sort of took the "optimal cache use" comment as tongue-in-cheek. If I am mistaken, correct me, but here is my perception of the scenario:
2 CPUs, 3 tasks. 1 task receives 100% of the CPU time on one CPU. The remaining two tasks share the second CPU. The result is, of three evenly prioritized tasks, one receives double as much CPU time as the others.
Quoted 4 lines
Aside from the cache utilization, this is not really "fair" -- the problem is, the current design of
load_balance(which is quite good) just won't throw the tasks around so readily. What could be done -- cleanly -- to make this better?
My opinion is: if it can be solved with no more than 20 lines of code let's do it, otherwise let's see what kind of catastrophe will happen by allowing such behavior. Because i've already seen hundreds of lines of code added to solve corner cases and removed after 3-4 years because someone realized that maybe such corner cases does not matter more than a whit.
I'll be happy to be shut down here ...
- Davide
Quoted 30 lines · Davide Libenzi
Quoted 14 lines · Robert Love
Quoted 3 lines · Timothy Covell
But, given the above case, what happens when you have Sendmail on the first CPU and Squid is sharing the second CPU? This is not optimal either, or am I missing something?
Correct. I sort of took the "optimal cache use" comment as tongue-in-cheek. If I am mistaken, correct me, but here is my perception of the scenario:
2 CPUs, 3 tasks. 1 task receives 100% of the CPU time on one CPU. The remaining two tasks share the second CPU. The result is, of three evenly prioritized tasks, one receives double as much CPU time as the others.
Quoted 4 lines
Aside from the cache utilization, this is not really "fair" -- the problem is, the current design of
load_balance(which is quite good) just won't throw the tasks around so readily. What could be done -- cleanly -- to make this better?My opinion is: if it can be solved with no more than 20 lines of code let's do it, otherwise let's see what kind of catastrophe will happen by allowing such behavior. Because i've already seen hundreds of lines of code added to solve corner cases and removed after 3-4 years because someone realized that maybe such corner cases does not matter more than a whit.
I'll be happy to be shut down here ...
Quoted 1 line
- Davide
There's always the 90/10 rule about 90% of the work being nescessary to get out the last 10% of improvements. It looks like you guys have been
working quite hard at this already and making good progress. Personally,
I have nothing to offer beyond the ideas of Francois.
Signature · 1 line
[email protected].
Quoted 7 lines · Davide Libenzi
My opinion is: if it can be solved with no more than 20 lines of code let's do it, otherwise let's see what kind of catastrophe will happen by allowing such behavior. Because i've already seen hundreds of lines of code added to solve corner cases and removed after 3-4 years because someone realized that maybe such corner cases does not matter more than a whit.
I'll be happy to be shut down here ...
Completely agreed. I think its an unfair situation (we may see administrators timing the order they start large batch tasks), but it is a corner case and we do have an "optimal cache use" counterargument.
Robert Love
In message <[email protected]> y ou write:
Quoted 8 lines
Quoted 4 lines
Aside from the cache utilization, this is not really "fair" -- the problem is, the current design of
load_balance(which is quite good) just won't throw the tasks around so readily. What could be done -- cleanly -- to make this better?My opinion is: if it can be solved with no more than 20 lines of code let's do it, otherwise let's see what kind of catastrophe will happen by allowing such behavior.
Agree. Anyone who really has 3 CPU hogs on a 2 CPU machine, *and* never runs two more tasks to perturb the system, *and* notices that one runs twice the speed of the other two, *and* cares about fairness (ie. not RC5 etc), feel free to Email abuse to me. Not Ingo, he has real work to do 8)
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.