> Dual PPro/180 running 2.1.79-SMP:
> SCHED_OTHER class: 56 microseconds
> SCHED_FIFO class: 3 microseconds
>
> Dual PPro/180 running 2.1.79-UP:
> SCHED_OTHER class: 40 microseconds
> SCHED_FIFO class: 2 microseconds
>
> Dual PPro/180 running 2.0.33-SMP:
> SCHED_OTHER class: 14 microseconds
> SCHED_FIFO class: 7 microseconds
>
> Dual PPro/180 running 2.0.33-UP:
> SCHED_OTHER class: 9 microseconds
> SCHED_FIFO class: 4 microseconds
hm, this cannot be explained with counter-recalculation only ... Here is
what happens on a Dual-P5, pre-2.1.80:
c010abd5 system_call +<39/48> (1.14) cpu(1) pid(441)
c01189c1 sys_sched_yield +<d/84> (2.91) cpu(1) pid(441)
c010abea ret_from_sys_call +<6/18> (0.97) cpu(1) pid(441)
c01172c3 schedule +<13/330> (2.76) cpu(1) pid(441)
c01174a9 schedule +<1f9/330> (22.05) cpu(1) pid(441) <-- (*)
c01174ec schedule +<23c/330> (1.49) cpu(1) pid(441)
c010abea ret_from_sys_call +<6/18> (2.21) cpu(1) pid(441)
this shows the counter-recalculation thing only [the line marked with
(*)]. As your board is about 4 times faster than mine, i should see 200
usecs if i had your problem ... It must be something else than the
sched_yield() change, maybe you have lots of processes? Or maybe it's the
for_each_task() over 100+ 8k-aligned task structures that are trashing the
cache? ...
or try ftp://ftp.ocs.com.au/pub/memleak+ktrace+xkdebug-patch to see where
the overhead is ...
-- mingo