Chris Friesen wrote:
William Lee Irwin III wrote:
The sorts of like explicit decisions I'd like to be made for these are:
(1) In a mixture of tasks with varying nice numbers, a given nice number
corresponds to some share of CPU bandwidth. Implementations
should not have the freedom to change this arbitrarily according
to some intention.
The first question that comes to my mind is whether nice levels should
be linear or not.
No. That squishes one end of the table too much. It needs to be
(approximately) piecewise linear around nice == 0. Here's the mapping I
use in my entitlement based schedulers:
#define NICE_TO_LP(nice) ((nice >=0) ? (20 - (nice)) : (20 + (nice) *
(nice)))
It has the (good) feature that a nice == 19 task has 1/20th the
entitlement of a nice == 0 task and a nice == -20 task has 21 times the
entitlement of a nice == 0 task. It's not strictly linear for negative
nice values but is very cheap to calculate and quite easy to invert if
necessary.
I would lean towards nonlinear as it allows a wider
range (although of course at the expense of precision). Maybe something
like "each nice level gives X times the cpu of the previous"? I think a
value of X somewhere between 1.15 and 1.25 might be reasonable.
What about also having something that looks at latency, and how latency
changes with niceness?
What about specifying the timeframe over which the cpu bandwidth is
measured? I currently have a system where the application designers
would like it to be totally fair over a period of 1 second.
Have you tried the spa_ebs scheduler? The half life is no longer a run
time configurable parameter (as making it highly adjustable results in
less efficient code) but it could be adjusted to be approximately
equivalent to 0.5 seconds by changing some constants in the code.
As you can
imagine, mainline doesn't do very well in this case.
You should look back through the plugsched patches where many of these
ideas have been experimented with.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
