Stephen C. Tweedie:
> Umm, what CPU is X going to run on in that case?
>
> You have two high-priority, interactive tasks to be scheduled: X and
> xosview. You have one low-priority background task --- the
> benchmark. If both xosview and X are ever runnable at the same time,
> then the benchmark task MUST be bumped off the cpu. And if the other
> cpu becomes free first, then what are you going to do? Leave it idle?
> That may win in some cases but in general it's a bad idea to bet that
> way.
Yes. We certanly have to take the whole box into account. Especially
when doing benchmarks (boot into a shell...)
But the point is: where have processes been scheduled the first
time. Let's say X started on cpu0 and has a strong tendency to stay there.
Somehow xosview made it to the same cpu0 after a wile. That could be
the outcome because the benchmark tends to be more active and xosview
more sleepy. Or whatever other constraints could influence process
migration and scheduling.
In fact it is a matter of balancing all constraints in a
reasonable way. There is no systematic way to achieve an optimal
balance. You can only try out different settings. Or invent new
constraints which grab a specific situation of the box in case the
once we have aren't enuf. These things are very fragile, but...
Micha.
-- -- Michael Schulz, NatS - Uni Hamburg- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:21 EST