* William Lee Irwin III <[email protected]> wrote:
>> Suppose a table of nice weights like the following is tuned via
>> /proc/:
>> -20 21 0 1
>> -1 2 19 0.0476
> > Essentially 1/(n+1) when n >= 0 and 1-n when n < 0.
On Sat, Apr 21, 2007 at 10:57:29AM +0200, Ingo Molnar wrote:
> ok, thanks for thinking about it. I have changed the nice weight in
> CVSv5-to-be so that it defaults to something pretty close to your
> suggestion: the ratio between a nice 0 loop and a nice 19 loop is now
> set to about 2%. (This something that users requested for some time, the
> default ~5% is a tad high when running reniced SETI jobs, etc.)
Okay. Maybe what I suggested is too weak vs. too strong. I didn't
actually have it in mind as a proposal for general use, but maybe it is
good for such. I had more in mind tunability in general, but it's all
good. I'd think some curve gentler in intermediate nice levels and
stronger at the tails might be better.
On Sat, Apr 21, 2007 at 10:57:29AM +0200, Ingo Molnar wrote:
> the actual percentage scales almost directly with the nice offset
> granularity value, but if this should be exposed to users at all, i
> agree that it would be better to directly expose this as some sort of
> 'ratio between nice 0 and nice 19 tasks', right? Or some other, more
> finegrained metric. Percentile is too coarse i think, and using 0.1%
> units isnt intuitive enough i think. The sysctl handler would then
> transform that 'human readable' sysctl value into the appropriate
> internal nice-offset-granularity value (or whatever mechanism the
> implementation ends up using).
I vaguely liked specifying the full table, but maybe it's too much
for a real user interface.
4-digit or 5-digit fixed point decimal sounds reasonable.
On Sat, Apr 21, 2007 at 10:57:29AM +0200, Ingo Molnar wrote:
> I'd not do this as a per-nice-level thing but as a single value that
> rescales the whole nice level range at once. That's alot less easy to
> misconfigure and we've got enough nice levels for users to pick from
> almost arbitrarily, as long as they have the ability to influence the
> max.
> does this sound mostly OK to you?
For the most part, yes. I've been mostly looking at how effectively
the prioritization algorithms work. I'll be wrapping up writing a
testcase to measure all this soon. The basic idea is to take the
weights as inputs somehow and then check to see that they're honored.
What's appropriate for end-users is a very different thing from what
might be appropriate for me. I won't have trouble fiddling with the
code, so please do design around what the best interface for end-users
might be.
-- wli
-
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/
- References:
- [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
- Re: [patch] CFS scheduler, v3
[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]
