Ok, I really don't care much for 2.2.x kernel series except for testing
purposes,
( to give a preview of what performance can be achieved with 2.4)
since it will be obsoleted by kernel 2.4 soon.
The important thing is that this kernel lock doesn't produce bad latencies on
2.3.x kernels.
Ingo, If you can confirm this then I have no further complaints.
(Did you get flat /proc on your latency tests on 2.3.x running on SMP ?
As far as I recall it seemed yes, right ?)
>
>
> there is a workaround: in reschedule_idle() whenever we wake up a RT
> process we could mark all running processes as 'reschedule ASAP' (set the
> need_resched flag). This guarantees that _someone_ will notice and
> reschedule eventually. (an SMP kernel is never worse than a UP kernel,
> latency-wise) This is only for RT tasks though. Do something like this at
> the beginning of reschedule_idle():
>
> if (policy != SCHED_OTHER)
> for (i = 0; i < smp_num_cpus; i++) {
> cpu = cpu_logical_map(i);
> tsk = cpu_curr(cpu);
> tsk->need_resched = 1;
> }
> /* continue doing the normal idle reschedule part */
>
> (this is of course an ugly hack, but if it makes a difference we can see
> how this could be done cleanly. It only affects RT tasks.)
>
> -- mingo
ok I will check out this.
Benno.
-
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/