lkml.org 
[lkml]   [2007]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Interesting interaction between lguest and CFS
    On 05/06/07, Matt Mackall <mpm@selenic.com> wrote:
    > > [...]
    > > Click into the lguest window and trigger the delay.
    >
    > I did:
    >
    > while true; do sleep 1; cat /proc/sched_debug > sched_debug.txt; done
    >
    > and got this, hopefully inside the window:
    >
    > Sched Debug Version: v0.02
    > now at 257428593818894 nsecs
    >
    > cpu: 0
    > .nr_running : 3
    > .raw_weighted_load : 2063
    > .nr_switches : 242830075
    > .nr_load_updates : 30172063
    > .nr_uninterruptible : 0
    > .jiffies : 64282148
    > .next_balance : 0
    > .curr->pid : 27182
    > .clock : 125650217819008823
    > .prev_clock_raw : 257428516403535

    The delta (clock - prev_clock_raw) looks insane.

    The current time (which doesn't depend on rq_clock() --> sched_clock() is
    " now at 257428593818894 nsecs " (right at the beginning of the output).

    'prev_clock_raw' is updated any time rq_clock() is called - basically
    upon any scheduling operation (e.g. enqueue/dequeue)

    now - prev_clock_raw == 257428593818894 - 257428516403535 == ~ 80 ms.

    while 'clock' reports something crazy.. that would explain why there
    wes a huge "block_max" reported earlier.. I guess, sched_clock() is
    tsc-based in your case?

    Any way to get it switched to jiffies-based one and repeat the test?


    --
    Best regards,
    Dmitry Adamushko
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-05 17:17    [W:0.024 / U:88.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site