Hi,
On Wed, 18 Jul 2007, Ingo Molnar wrote:
> > Why do you constantly stress level 19? Yes, that one is special, all
> > other positive levels were already relatively consistent.
>
> i constantly stress it for the reason i mentioned a good number of
> times: because it's by far the most commonly used (and complained about)
> nice level. =B-)
How do you know that? Most complained about makes most commonly used?
> but because you are asking, i'm glad to give you some first-hand
> historic background about Linux nice levels (in case you are interested)
> and the motivations behind their old and new implementations:
I guess I should be thankful now?
I'm curious why you post this now, after I "asked" about this. Most of the
information is either rather generic or not specific enough for the
problem at hand. If you had posted this information earlier, it had been
far more valueable as it could have been a nice base for a discussion.
But posting it this late I can't lose the feeling you're more interested
in "teaching" me.
> nice levels were always so weak under Linux (just read Peter's report)
-ENOLINK
> Hope this helps,
Not completely.
For negative nice levels you mentioned audio apps, but these aren't really
interested in a fair share, they would use the higher percentage only to
guarantee they get the amount of time they need independent of the
current load. I think they would be better served with e.g. a deadline
scheduler, which guarantees them an absolute time share not a relative
one.
On the other end with positive levels I more remember requests for
something closer to idle scheduling, where a process only runs when
nothing else is running.
So assuming we had scheduling classes for the above use cases, what other
reasons are left for such extreme nice levels?
My proposed nice levels have otherwise the same properties as yours (e.g.
being consistent). There is one propery you haven't commented on at all
yet. My proposed levels give the average use a far better idea what they
actually mean, i.e. that every 5 levels the process gets double/halve the
cpu time. This is IMO a considerable advantage.
bye, Roman
-
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]