Re: [git pull] scheduler changes for v2.6.26

[Kevin Winchester <kjwinchester@gmail.com>]

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