lkml.org 
[lkml]   [2008]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-04-22 12:25    [from the cache]
©2003-2011 Jasper Spaans