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    [W:0.030 / U:29.224 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site