Messages in this thread | | | Date | Tue, 22 Apr 2008 06:41:47 -0300 | From | Kevin Winchester <> | Subject | Re: [git pull] scheduler changes for v2.6.26 |
| |
Ingo Molnar wrote: > * Frans Pop <elendil@planet.nl> wrote: > >>> It would be nice if you could try sched-devel/latest because it has >>> an improved ftrace "sched_switch" tracer where you can generate much >>> longer traces of this incident. Try the new /debug/trace_entries >>> runtime tunable. >> I'll try to get the trace and will reply on the private thread we had. >> I may need additional instructions though. > > you could also reply to this thread if you dont mind, so that others can > chime in too. > > the 700-800 msecs of delays you see are very "brutal" so there must be > something fundamentally wrong going on here. > > Could you first check (under sched-devel/latest) the quality of your > sched-clock, via running this script: > > http://people.redhat.com/mingo/cfs-scheduler/tools/watch-rq-clock.sh > > if you run it, it should output ~1000 msecs periods every second: > > europe:~> watch-rq-clock.sh > 1002.115042 > 1005.509851 > 1004.187275 > 1004.409980 > 1004.430264 > 1004.445508 > > if it's way too 'slow', say it only 100 msecs per second, then the > scheduler clock is mis-measuring time and what the scheduler thinks to > be a 40 msecs delay might become a 400 msecs delay. >
Is this supposed to be true for everyone?
kevin@alekhine:~/linux$ uname -a Linux alekhine 2.6.25-02519-g3925e6f #10 PREEMPT Sat Apr 19 12:36:49 ADT 2008 x86_64 GNU/Linux
kevin@alekhine:~/linux$ ./watch-rq-clock.sh 89.986517 81.033471 76.942776 90.986318 75.988551 85.987089 74.988696 85.987078 73.988858 88.986641 68.989600
kevin@alekhine:~/linux$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3000+ stepping : 0 cpu MHz : 1000.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good lahf_lm bogomips : 2006.79 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp
Does that mean anything? Is there any other testing I should perform?
-- Kevin Winchester
| |