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

From: Kevin Winchester
Date: Tue Apr 22 2008 - 06:23:41 EST


Ingo Molnar wrote:
* Frans Pop <elendil@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/