> It looks to me that the underlying problem is that xosview steals the
> CPU that the number cruncher is running on, instead of using the other
> CPU (which I presume is idle). That shouldn't happen. If it does, it's
> a bug.
this is not a bug, it's because xosview is an 'interactive' process, and
such it has higher priority. (and the right to kick a lowprio process out,
especially if xosview ran on that CPU previously). Btw., xosview's active
timeslice is several msecs on a typical SMP box, so this is definitely not
an outright bad decision by the scheduler.
i have the plan to do per-process and per-CPU 'cache-set tracking' via
performance counters in 2.3 (basically what you see in 2.2 is already a
variant of this). That one has a chance to weigh a process's priority with
it's active cachesize.
anyway, even with 2.2.5 the expected behavior is that the number-cruching
process settles on one CPU after some initial ping-pong, and xosview
settles on some other CPU. If this does not happen _thats_ a bug. Anyway,
be careful with xosview, it's obviously a bit tricky to measure scheduling
with a tool that itself is rather intrusive as well ...
-- mingo
-
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/