Ingo Molnar wrote:
* Davide Libenzi <[email protected]> wrote:
The same user nicing two different multi-threaded processes would
expect a predictable CPU distribution too. [...]
i disagree that the user 'would expect' this. Some users might. Others
would say: 'my 10-thread rendering engine is more important than a
1-thread job because it's using 10 threads for a reason'. And the CFS
feedback so far strengthens this point: the default behavior of treating
the thread as a single scheduling (and CPU time accounting) unit works
pretty well on the desktop.
If by desktop you mean "one and only one interactive user," that's true.
On a shared machine it's very hard to preserve any semblance of fairness
when one user gets far more than another, based not on the value of what
they're doing but the tools they use to to it.
think about it in another, 'kernel policy' way as well: we'd like to
_encourage_ more parallel user applications. Hurting them by accounting
all threads together sends the exact opposite message.
Why is that? There are lots of things which are intrinsically single
threaded, how are we hurting hurting multi-threaded applications by
refusing to give them more CPU than an application running on behalf of
another user? By accounting all threads together we encourage writing an
application in the most logical way. Threads are a solution, not a goal
in themselves.
[...] Doing that efficently (the old per-cpu run-queue is pretty nice
from many POVs) is the real challenge.
yeah.
Ingo
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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]
