Balbir Singh wrote:
On 5/28/06, Peter Williams <[email protected]> wrote:
<snip>
>
> That behaviour would be fair.
Caps aren't about being fair. In fact, giving a task a cap is an
explicit instruction to the scheduler that the task should be treated
unfairly in some circumstances (namely when it's exceeding that cap).
Similarly, the interactive bonus mechanism is not about fairness either.
It's about giving tasks that are thought to be interactive an unfair
advantage so that the user experiences good responsiveness.
I understand that, I was talking about fairness between capped tasks
and what might be considered fair or intutive between capped tasks and
regular tasks. Of course, the last point is debatable ;)
Well, the primary fairness mechanism in the scheduler is the time slice
allocation and the capping code doesn't fiddle with those so there
should be a reasonable degree of fairness (taking into account "nice")
between capped tasks. To improve that would require allocating several
new priority slots for use by tasks exceeding their caps and fiddling
with those. I don't think that it's worth the bother.
When capped tasks aren't exceeding their cap they are treated just like
any other task and will get the same amount of fairness.
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]
