Tuesday 18 November 2014

BFS 458, linux-3.17-ck2

This is a bugfix release for the power usage regression as reported here with BFS 457.

BFS by itself:

CK branded BFS separate and combined patches:

Incremental change from BFS 457-458:



  1. Hmm I guess now we've got some problem with loadavg value, which doesn't go below 1.0 even after continuous idling.

    1. That's odd, I'm not seeing anything like that on any of the machines I'm running it on. You sure you don't have some distro background process annoyingly consistently eating cycles? They've been known to do that on occasion... :P

    2. Used top/htop/perf top to discover such processes/kernel threads with no luck.

    3. Everything, including loadavg, normal here since this patch. Thanks for your hard work!

    4. @PF, sorry no idea why it's unique to you. Maybe some choice of idle governor/dynticks that no one else is using. No one else is seeing it.

    5. OK, will try to manage that somehow.

  2. Excellent work, CK. Idle C7 problem on Haswell quad has been resolved.

    Cpu speed from cpuinfo 3999.00Mhz
    cpuinfo might be wrong if cpufreq is enabled. To guess correctly try estimating via tsc
    Linux's inbuilt cpu_khz code emulated now
    True Frequency (without accounting Turbo) 3999 MHz
    CPU Multiplier 40x || Bus clock frequency (BCLK) 99.97 MHz

    Socket [0] - [physical cores=4, logical cores=8, max online cores ever=4]
    TURBO ENABLED on 4 Cores, Hyper Threading ON
    Max Frequency without considering Turbo 4098.97 MHz (99.97 x [41])
    Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is 44x/44x/44x/44x
    Real Current Frequency 2313.55 MHz [99.97 x 23.14] (Max of below)
    Core [core-id] :Actual Freq (Mult.) C0% Halt(C1)% C3 % C6 % C7 % Temp VCore
    Core 1 [0]: 2313.55 (23.14x) 1.7 0 1 1 97.3 23 1.2190
    Core 2 [1]: 2107.33 (21.08x) 1 0 1 1 98.6 23 1.2213
    Core 3 [2]: 2231.20 (22.32x) 1 0.225 0 0 99.6 23 1.2177
    Core 4 [3]: 1451.59 (14.52x) 1 0.0373 0 0 100 21 1.2197

    C0 = Processor running without halting
    C1 = Processor running with halts (States >C0 are power saver modes with cores idling)
    C3 = Cores running with PLL turned off and core cache turned off
    C6, C7 = Everything in C3 + core state saved to last level cache, C7 is deeper than C6
    Above values in table are in percentage over the last 1 sec
    [core-id] refers to core-id number in /proc/cpuinfo
    'Garbage Values' message printed when garbage values are read

  3. ...now what about you opening up a github account for hosting your patch set and for discussion?

    1. @CK: Maybe, some people of your community _just_ want releases of CK/BFS to happen _closer_ to main kernel releases ?! ;-) (Thought about that?)
      This shouldn't sound impolite. We all appreciate your work on CK/BFS and respect your real life, and, of course, I -- and maybe all others -- thank you very much for any effort!
      I don't need github to fetch a good CK/BFS patchset... :-P

      Manuel Krause

    2. I am aware of your previous git discussion. I suggest github not so you can keep things in sync in an incremental fashion but for all the other wonderful features including:

      * A very nice bug tracking system within the interface (called issues)

      * Uses git which is a standard and will encourage others to contribute to your code, they can send you very convenient pull requests

      * It's free :)

    3. @graysky: What about publishing some more of your earlier great benchmarking charts, rather than doing this dubious advertisement thingy? Manuel

  4. I'd like to report that the bug derscribed here --> ck-hack.blogspot.dk/2014/08/bfs-453454455456-and-316-ck2.html is still present because same thing happened at me yesterday. I made a post on manjaro's forum to describe the situation. here it is --> https://forum.manjaro.org/index.php?topic=18048.0

    1. I don't see which bug you're referencing on the old bfs blogspot entry. Nothing matches what you're describing in that BFS post or the comments.

    2. "The main obvious bug which affected people was the ath9k module which would hang on suspend/resume" i'm referring to this bug (but I don't know if it depends on the same problem with that module)

    3. The ath9k module bug was fixed.

    4. good! so I don't know why i have that problem! :D

  5. Finally 3.17.3 is out and BFS 0458 is stabilized. Then, 3.17.4 is out too. I just rebased my -gc branch and make a new tag for it.

    @ck, there are some patches on my -gc branch which I recommend to be considered in the next bfs release. Please have a check and comments will be welcome.

    Please check the commits in https://bitbucket.org/alfredchen/linux-gc/commits/tag/v3.17.4-gc

    BR Alfred

  6. https://randomascii.wordpress.com/2013/03/18/counting-to-ten-on-linux/
    Anyone tested this from a BFS with SMT/Nice patch ?

    1. Interesting test and worth trying on BFS. SMT nice will have no effect on it though since there is no use of nice levels affecting behaviour.