Thursday, November 23, 2017

PDS 0.98g release

PDS 0.98g is released with the following changes

1. Fix rq->online is default false for cpu 0, issue reported by Manuel.
2. Remove update_rq_clock() in hrtick(), it's a minor enhancement.

This is a bug fix/enhancement release. After bug fixes for the new features in the recent releases, I have done a kernel compilation benchmark in 4.14. The results are as expected, but it also indicate that the overhead under high workload is larger than CFS. So, reduce scheduling/balance/migration overhead will the next feature in the todo list. But don't expect such features will be coming soon, as current PDS is stable, I'll tend to slow down and do more research before rolling out new features.

One more thing, current release of PDS is running well on raspberry pi, you can have a try if you own a raspberry pi soc.

Anyway, enjoy PDS 0.98g for v4.14 kernel, :)

code are available at
https://bitbucket.org/alfredchen/linux-gc/commits/branch/linux-4.14.y-pds
and also
https://github.com/cchalpha/linux-gc/commits/linux-4.14.y-pds

 All-in-one patch is available too.

16 comments:

  1. Hey Alfred; I'm running this on x64 now. Thanks as always! I was away for a while testing 4.14-rc's and then linux-next, but have now synced back to 4.14. Everything is fine so far, but when I build x86 UP, I get this:
    kernel/sched/pds.c: In function ‘sched_init’:
    kernel/sched/pds.c:6274:11: error: ‘struct rq’ has no member named ‘online’
    cpu_rq(0)->online = true;
    [The `->` is highlighted.]

    ReplyDelete
    Replies
    1. Do I just need a "#ifdef CONFIG_SMP" wrapped around that line? I will try it tonight...

      Delete
    2. @jwh7
      Yes, that would be the fix.
      I will include it in next release. Thanks for the reporting.

      Delete
    3. Btw, I did build i686 UP last week; pds+bfq w/ Ming's I/O Perf, Bart's suspend/resume, 4.15 BFQ, some other patches. I tested it on my netbook over the weekend, including suspend/resume; working fine. Same for my x64 PC too; thanks!

      Delete
  2. Alfred,

    could you please check build log for PowerPC [1]? It fails on cpu_coregroup_mask() because it is not defined for PowerPC architecture. I think the respective code should be wrapped into CONFIG_SCHED_MC ifdef, but wanted to check with you first.

    [1] https://kojipkgs.fedoraproject.org//work/tasks/9440/23559440/build.log

    ReplyDelete
    Replies
    1. @pf
      Sorry for the late reply. Please try the patch below, if it works, I will include it in next release.

      diff --git a/kernel/sched/pds.c b/kernel/sched/pds.c
      index 722f357a782b..fcc7ee0c8091 100644
      --- a/kernel/sched/pds.c
      +++ b/kernel/sched/pds.c
      @@ -6155,7 +6155,14 @@ static void sched_init_topology_cpumask(void)
      per_cpu(sd_llc_id, cpu) =
      cpumask_first(cpu_coregroup_mask(cpu));

      +#ifdef CONFIG_SCHED_MC
      cpumask_complement(&tmp, cpu_coregroup_mask(cpu));
      +#elif CONFIG_SCHED_SMT
      + cpumask_complement(&tmp, topology_sibling_cpumask(cpu));
      +#else
      + cpumask_setall(&tmp);
      + cpumask_clear_cpu(cpu, &tmp);
      +#endif
      if (cpumask_and(&tmp, &tmp, topology_core_cpumask(cpu))) {
      printk(KERN_INFO "pds: sched_cpu_affinity_chk_masks[%d] core 0x%08lx",
      cpu, tmp.bits[0]);

      Delete
    2. @Oleksandr Natalenko/ @post-factum/ @pf:
      An applicable patch of this uploaded here by me for reference:
      https://pastebin.com/HSkZrzB1

      Have you had a chance to (let) test this one?

      BTW, Oleksandr, again many thanks for your work on your patchset, especially for keeping track of all the BFQ I/O improvements.

      BR, Manuel Krause

      Delete
    3. This issue was reported not by me, and I do not have a possibility to test the fix, thus still waiting for the response from the relevant user.

      Delete
    4. @pf
      It is ok. I will include this fix in next release. And add more fix in if there is still an issue reported by the relevant user.

      Delete
    5. Thank you both for your replies! Just wanted to be informed until 2018 faces.
      BR, Manuel Krause

      Delete
  3. Thanks Alfred.
    I've done the usual throughput tests with PDS 0.98g.

    https://docs.google.com/spreadsheets/d/163U3H-gnVeGopMrHiJLeEY1b7XlvND2yoceKbOvQRm4/edit?usp=sharing

    As you already noted, there is a slight regression comparing to linux 4.13 + PDS 0.98d,
    but the results are still within +- 1% of CFS.

    Pedro

    ReplyDelete
    Replies
    1. Great work!

      It would be interesting to also compare the MuQSS with int0 and RQSHARE_MC=y.

      Delete
    2. Thanks for this third party tests.
      The most important featrue of this year would be the smt group rebalance, it helps the performance when using number of physical cores(make -j4 in the tests).
      PDS will focus on reducing overhead next year.

      Delete
    3. Hi,

      This will be interesting, Alfred! So, You'll improve already exising SMT sensitive scheduling? If You need alpha/beta tester w/ Ryzen, shoot me an e-mail. Since Ryzen have those ccx, it behaves behaves a bit differently.

      BR, Eduardo

      P.S. I already tried muqss builds with both smt and mc, results are mixed as Con predicted. Diablo3, as with vrq back in the day, still had interesting scheduler behaviour :)

      Delete
    4. @Alfred:
      I'm really confident with the current state! :-)
      But please, also let us all others know of possible improvements to be tested. Speaking for me, I'm too curious for the new, and the others don't need to take a risk.

      BR, Manuel Krause

      Delete
    5. @all
      Sorry for late reply. It has been busy these days.
      I am working on an improvement to reduce re-balance overhead to 3/4 or 3/8, hopefully there will be debug patch for testing in Jan 2018.

      Delete