Chris Friesen wrote:
Mark Glines wrote:
One minor question: is it even possible to be completely fair on SMP?
For instance, if you have a 2-way SMP box running 3 applications, one of
which has 2 threads, will the threaded app have an advantage here? (The
current system seems to try to keep each thread on a specific CPU, to
reduce cache thrashing, which means threads and processes alike each
get 50% of the CPU.)
I think the ideal in this case would be to have both threads on one cpu,
with the other app on the other cpu. This gives inter-process fairness
while minimizing the amount of task migration required.
Solving this sort of issue was one of the reasons for the smpnice patches.
More interesting is the case of three processes on a 2-cpu system. Do
we constantly migrate one of them back and forth to ensure that each of
them gets 66% of a cpu?
Depends how keen you are on fairness. Unless the process are long term
continuously active tasks that never sleep it's probably not an issue as
they'll probably move around enough in the long term for them each to
get 66% over the long term.
Exact load balancing for real work loads (where tasks are coming and
going, sleeping and waking semi randomly and over relatively brief
periods) is probably unattainable because by the time you've work out
the ideal placement of the currently runnable tasks on the available
CPUs it's all changed and the solution is invalid. The best you can
hope for that change isn't so great as to completely invalidate the
solution and the changes you make as a result are an improvement on the
current allocation of processes to CPUs.
The above probably doesn't hold for some systems such as those large
super computer jobs that run for several days but they're probably best
served by explicit allocation of processes to CPUs using the process
affinity mechanism.
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]
