lkml.org 
[lkml]   [1998]   [Jan]   [22]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 22 Jan 1998 09:51:22 +0100 (CET)
FromMOLNAR Ingo <>
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008