lkml.org 
[lkml]   [2005]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Updated: Dynamic Tick version 050408-1
    Frank Sorenson wrote:
    > Tony Lindgren wrote:
    > | * Tony Lindgren <tony@atomide.com> [050407 23:28]:
    > |
    > |>I think I have an idea on what's going on; Your system does not wake to
    > |>APIC interrupt, and the system timer updates time only on other
    > interrupts.
    > |>I'm experiencing the same on a loaner ThinkPad T30.
    > |>
    > |>I'll try to do another patch today. Meanwhile it now should work
    > |>without lapic in cmdline.
    > |
    > |
    > | Following is an updated patch. Anybody having trouble, please try
    > | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option.
    > |
    > | I'm hoping this might work on Pavel's machine too?
    > |
    > | Tony
    >
    > This updated patch seems to work just fine on my machine with lapic on
    > the cmdline and CONFIG_DYN_TICK_USE_APIC disabled.
    >
    > Also, you were correct that removing lapic from the cmdline allowed the
    > previous version to run at full speed.
    >
    > Now, how can I tell if the patch is doing its thing? What should I be
    > seeing? :)
    >
    > Functionally, it looks like it's working. There were a number of
    > compiler warnings you might wish to fix before calling it good. Such as
    > "initialization from incompatible pointer type" several times in
    > dyn-tick-timer.c and a "too many arguments for format" in
    > dyn_tick_late_init.
    >

    Here are some figures about idle/C-states:

    Passing bm_history=0xF to processor module makes it going into C3 and deeper.
    Passing lower values, deeper states are reached more often, but system could freeze:

    bm_activity=0x4
    bus master activity: fefffffd
    states:
    C1: type[C1] promotion[C2] demotion[--] latency[001] usage[00000010]
    *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[00007183]
    C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[00000515]
    C4: type[C3] promotion[--] demotion[C3] latency[185] usage[00000330]

    bm_activity=0x1
    bus master activity: ffff7ffd
    states:
    C1: type[C1] promotion[C2] demotion[--] latency[001] usage[00000010]
    *C2: type[C2] promotion[C3] demotion[C1] latency[001] usage[00005495]
    C3: type[C3] promotion[C4] demotion[C2] latency[085] usage[00000537]
    C4: type[C3] promotion[--] demotion[C3] latency[185] usage[00000472]


    Figures NO_IDLE_HZ disabled, HZ=1000 (max sleep 1ms)
    (Don't trust the figures too much, there probably are little bugs...):

    Active C0/C1 state:
    Total(ms): 145
    Usage: 20205
    Failures: 0
    Maximum(us): 1967
    Average(us): 7
    Sleep C2 state:
    Total(ms): 19306
    Usage: 20074
    Failures: 0
    Maximum(us): 1275 (-> strange max should be 1000us)
    Average(us): 961
    Sleep C3 state:
    Total(ms): 34
    Usage: 131
    Failures: 0
    Maximum(us): 984
    Average(us): 259
    Measures based on ACPI PM timer reads

    Total switches between C-states: 20205
    Switches between C-states per second: 1063 per second
    Total measure time (s): 19
    Total measure time (based on starting measures) (s): 20


    Figures NO_IDLE_HZ enabled, processor.bm_history=0xF HZ=1000:
    (Don't trust the figures too much, there probably are little bugs...):

    Active C0/C1 state:
    Total(ms): 81
    Usage: 4659
    Failures: 0
    Maximum(us): 1608
    Average(us): 17
    Sleep C2 state:
    Total(ms): 71108
    Usage: 4241
    Failures: 0
    Maximum(us): 49921
    Average(us): 16766
    Sleep C3 state:
    Total(ms): 219
    Usage: 167
    Failures: 0
    Maximum(us): 28296
    Average(us): 1311
    Sleep C4 state:
    Total(ms): 374
    Usage: 251
    Failures: 0
    Maximum(us): 18870
    Average(us): 1490
    Measures based on ACPI PM timer reads

    Total switches between C-states: 4659
    Switches between C-states per second: 65 per second
    Total measure time (s): 71
    Total measure time (based on starting measures) (s): 75


    I buffer C-state times in an array and write them to /dev/cstX.
    From there I calc the stats from userspace.

    Tony: If you like I can send you the patch and dump prog for
    http://www.muru.com/linux/dyntick/ ?

    I try to find a better algorithm (directly adjust slept time to
    C-state latency or something) for NO_IDLE_HZ (hints are very welcome)
    and try to come up with new figures soon.


    Thomas
    -
    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: 2005-04-08 13:39    [W:0.028 / U:0.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site