Messages in this thread | | | Date | Thu, 22 Jan 1998 09:51:22 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: Scheduler latency |
| |
On Thu, 22 Jan 1998, Richard Gooch wrote:
> 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
| |