OK, I think what this means is that under X you had more processes on
the run queue. Since the scheduler has to scan the run queue, the
longer it is the more time the scheduler takes.
You can see the effect of this by using the <num_running> option: this
will add the specified number of (low priority) processes to the run
queue. Increasing this number will slow the scheduler down.
In fact, this indicates that Linux only maintains a single run
queue. It could be argued that for RT performance, we'd be better off
with two run queues: one for SCHED_OTHER and the other for RT
scheduling classes. This way scheduling times for RT processes would
not be affected by the number of normal processes on the run
queue. However, it could be counter-argued that there are not usually
many processes on the run queue anyway. This is likely true for
embedded systems, but isn't necessarily the case for a large system
controlling an instrument as well as supporting users [1].
Another possible advantage of separating the run queue would be that
it would then become cheap to *always* call schedule() (or perhaps
schedule_rt()) upon return from interrupt/syscall. In most cases there
won't be any RT processes on the run queue, so this would only add a
few cycles overhead to the scheduler.
The advantage of doing this is that RT processes which are woken up
by a driver will preempt whatever is currently running, and hence will
actually start running immediately, rather than waiting N
jiffies. This would make Linux more RT-friendly.
Linus: what do you think of this idea? A valid project for 2.3?
I have to say I'm impressed with the soft-RT performance of Linux. In
my view the main limitation is the jiffies delay between when an RT
process is unblocked and when it starts running.
> But i thought that software switch is faster than hardware.
Not always. See Linus' message about this.
> Other point is if this times can be correctly computed from user
> level?
We have a pretty accurate gettimeofday(2) syscall, which makes doing
this easy. Particularly on the Pentium and above, where we use the TSC
for greater accuracy. I'm not sure how good it is on the 486 and
lower. In any case, in my code I'm careful to amortise the cost of
getting the time and reducing the inaccuracies of the timestamp by
running through the scheduler in a loop.
Regards,
Richard....
-
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/