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

 Edit:
Missed one api changes for SMT, here is the update patch.
Posted by at
Labels: , , ,

11 comments:

  1. AnonymousSeptember 4, 2015 at 1:43 AM

    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?

    ReplyDelete
  2. AnonymousSeptember 4, 2015 at 8:15 PM

    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

    ReplyDelete
  3. kernelOfTruthSeptember 14, 2015 at 3:17 PM

    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 !

    ReplyDelete
    Replies
    1. Alfred ChenSeptember 14, 2015 at 7:39 PM

      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

      Delete
  4. AnonymousSeptember 15, 2015 at 7:37 AM

    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/Makefile.build:258: recipe for target 'kernel/sched/bfs.o' failed
    make[2]: *** [kernel/sched/bfs.o] Error 1
    scripts/Makefile.build:403: 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)
    +// {
    +// }

    #ifdef CONFIG_NO_HZ_COMMON
    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

    ReplyDelete
    Replies
    1. AnonymousSeptember 15, 2015 at 7:51 AM

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

      Delete
    2. AnonymousSeptember 15, 2015 at 9:38 AM

      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);
      #else
      static inline void update_cpu_load_nohz(void) { }
      #endif

      extern unsigned long get_parent_ip(unsigned long addr);

      extern void dump_cpu_task(int cpu);

      struct seq_file;

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

      Delete
    3. Alfred ChenSeptember 15, 2015 at 5:41 PM

      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

      Delete
    4. AnonymousSeptember 22, 2015 at 5:26 PM

      Comments are not accepted. :-(

      Delete
  5. Jorge Pizarro CallejasOctober 23, 2015 at 5:03 PM

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

    http://pastebin.com/6rxWULKK

    :)

    ReplyDelete

Subscribe to: Post Comments (Atom)