Thursday, September 3, 2015

4.2 Sync up completed for -gc branch

It's good to announce that my 4.2 bfs sync up work has been completed for -gc branch. Lots of sync up work in 4.2, considering the code diff between the -gc and -vrq, some of the sync-up code would be just done in -vrq branch.

Basically, there is no new code for -gc branch, just pick up

bfs: [Fix] Add additional checking in sched_submit_work()
from my latest post.

There are total three reports that there are issue caused in resched_closest_idle(). I am considering remove this function in -gc as there is a total replacement implement in -vrq branch, but I'm still waiting for the feedback to decide to remove both two calls or may be just one of them. So there will be an update once it's finalized. And as upstream asm code clean-up, some X86 cpumask api is no longer supported, but good news is we using more generic ones, this happens in 

bfs: Full cpumask based and LLC sensitive cpu selection, v3

At this point of time, some upstream patch, like BFQ is not yet updated, so the official -gc branch is not created yet, but there is a linux-4.2.y-bfs branch on bitbucket and github, which contains all bfs related commits in -gc branch for kernel 4.2. And there is an all-in-one patch file you can apply upon vanilla kernel tree easily.

Have fun with 4.2 and reports back if any related issue with this porting of bfs.

BR Alfred

Missed one api changes for SMT, here is the update patch.


  1. kernel/sched/bfs.c:7058:9: error: implicit declaration of function ‘topology_thread_cpumask’ [-Werror=implicit-function-declaration]

    use topology_sibling_cpumask() instead of it?

  2. At the moment I do stay with the -vrq for 4.1.6. It's rock solid for weeks now. Thank you very much for it !!!
    As long as the other patches don't get updated... I don't need 4.2.
    I've already seen, that the resched_closest_idle() isn't valid in -vrq any more, and hope that the related code hasn't found a way into the replacement code.

    So, I'd only like to say that I'm really looking forward to your updated -vrq.

    My very best wishes for your future work and
    kind regards,

    Manuel Krause

  3. Just to make sure that is the correct way I get it:

    SMT_NICE support it currently disabled ?

    because it's no where in .config and also not reachable via menuconfig

    Thanks !

    1. I haven't disabled SMT_NICE, it should be right follow SMT config when you enable SMT. But I not guarantee it works well in -gc and -vrq.
      SMT is a quit funny thing in new cpu topology, I am playing with it in this release and will see if any adjustment related to it.

      BR Alfred

  4. O.K. I'm now at the end of upgrading my openSUSE.

    I patched the 4.2.0 vanilla with your 30 patches from the current -bfs branch.
    While compiling I got this:
    --- --- ---
    LD kernel/rcu/built-in.o
    CC kernel/sched/bfs.o
    CC arch/x86/kernel/cpu/mcheck/mce_intel.o
    kernel/sched/bfs.c:2795:6: error: redefinition of ‘update_cpu_load_nohz’
    void update_cpu_load_nohz(void)
    In file included from include/linux/nmi.h:7:0,
    from kernel/sched/bfs.c:33:
    include/linux/sched.h:182:20: note: previous definition of ‘update_cpu_load_nohz’ was here
    static inline void update_cpu_load_nohz(void) { }
    CC arch/x86/kernel/cpu/mcheck/threshold.o
    scripts/ recipe for target 'kernel/sched/bfs.o' failed
    make[2]: *** [kernel/sched/bfs.o] Error 1
    scripts/ recipe for target 'kernel/sched' failed
    make[1]: *** [kernel/sched] Error 2
    Makefile:949: recipe for target 'kernel' failed
    make: *** [kernel] Error 2
    make: *** Waiting for unfinished jobs....
    CC arch/x86/mm/init.o
    CC arch/x86/kernel/cpu/mcheck/therm_throt.o
    LD arch/x86/kernel/cpu/mcheck/built-in.o
    --- --- ---

    I only got rid of it by doing this:

    --- /usr/src/linux-4.2.0-6.TEST-GC/kernel/sched/bfs.c.orig 2015-09-15 12:44:31.000000000 +0200
    +++ /usr/src/linux-4.2.0-6.TEST-GC/kernel/sched/bfs.c 2015-09-15 13:53:14.000000000 +0200
    @@ -2792,9 +2792,9 @@

    -void update_cpu_load_nohz(void)
    +// void update_cpu_load_nohz(void)
    +// {
    +// }

    void calc_load_enter_idle(void)
    --- --- ---

    ... and I really don't know if the occurrence of ‘update_cpu_load_nohz’ is correct in my "include/linux/sched.h" in comparison to your 4.2.0 setup.

    Sorry, if the patch above is trashed someway, it's trashed by your blogspot interface already at input time.

    I'm really looking forward to the VRQ for the 4.2 kernel.

    Best regards, Manuel Krause

    1. Oh, sorry, I forgot to add:
      Yes, the 4.2-gcBFS kernel runs fine, with the TuxOnIce patch plus the fresh BFQ v7r9.

    2. The relevant section of my "include/linux/sched.h" looks like:
      --- --- ---
      extern void calc_global_load(unsigned long ticks);

      #if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
      extern void update_cpu_load_nohz(void);
      static inline void update_cpu_load_nohz(void) { }

      extern unsigned long get_parent_ip(unsigned long addr);

      extern void dump_cpu_task(int cpu);

      struct seq_file;

      --- --- ---
      BR, Manuel

    3. Thanks for this investigation, I have fixed this last night and preparing a new -gc release(with bfq patch), but it's too late to test and push to git.

      BR Alfred

    4. Comments are not accepted. :-(

  5. Hi! This happens when I try to compile the 4.2.4 version: