Friday, April 14, 2017

VRQ 0.95 release

VRQ 0.95 is released with the following changes

1. Fix compilation issue with CONFIG_CPUSETS(thanks Dzon reporting this)
2. Introduce hrtimer for task time slice expiration.
3. NO_HZ_FULL support
4. cpumask topology output in hex format.
5. use cpu_online_mask in sched_init_topology_cpumask(), this fix wrong topology setup for some system.

The most important feature in this release is introduce hrtimer for task time slice expiration and re-enable NO_HZ_FULL support.

For issues, Dazon also report his issue that unable to achieve full cpu utilization in kernel compilation. And I am still investigating, anyone else has similar issue could let me know.

In next release, SMT improvement is in the plan list.


Enjoy VRQ 0.95 for v4.10 kernel, :)


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

All-in-one patch is available too.

BR Alfred 
Posted by at
Labels: , , , , ,

33 comments:

  1. AnonymousApril 14, 2017 at 7:42 AM

    @Alfred:
    Thank you very much for this Easter egg. Compiles fine and runs well (for ~an hour now).
    Now @4.10.10 with BFQ and with CONFIG_TICK_CPU_ACCOUNTING=y (now appearing as new and default).
    Like with the predecessor I don't see issues with my non-gaming workloads. Also kernel compilation in the presence of idle-load WCG clients loads both non-HT cores equally, as before.

    Thank you very much for your continued good work!
    I don't know if you personally celebrate Easter, but anyways, have good days!
    And I'm looking forward to your planned efforts. :-)

    BR, Manuel Krause

    ReplyDelete
    Replies
    1. Alfred ChenApril 15, 2017 at 8:04 PM

      Thanks @Manuel
      There is not tradition here to celebrate Easter, but I got one day holiday to enjoy movie with friends, :)

      Delete
    2. AnonymousApril 16, 2017 at 8:57 AM

      @Alfred:
      I cannot confirm kernelOfTruth's experience of a "snappier" system, reported below, as the differences got less distinguish-able on here. For my subjective feeling it's as least as fine as before.
      What I see after ~48h is more stability/ reliability and faster recovery speeds at resumes from hibernation.
      Let me add, that the result can also be positively influenced by updated Mesa and updated Firefox-ESR.

      I personally don't either celebrate Easter, but enjoy your VRQ scheduler in the background atm. very much.

      BR, Manuel Krause

      Delete
  2. Oleksandr NatalenkoApril 15, 2017 at 3:59 AM

    Compiled and booted okay. Giving it another try to find out whether freezes are fixed :).

    ReplyDelete
    Replies
    1. Alfred ChenApril 15, 2017 at 8:07 PM

      Oh, that reminds your freezen issue, good luck with with the try, and it happens only on amd hardware?

      Delete
    2. Oleksandr NatalenkoApril 15, 2017 at 10:38 PM

      Nope, it happened on Intel Ivy Bridge only for me.

      If it happens again, I'm going to recompile kernel with some extra debug options and undefined behavior checkers enabled. Maybe, that would give some hint.

      Delete
  3. kernelOfTruthApril 15, 2017 at 4:09 PM

    Feels snappier than before,

    thank you :)

    ReplyDelete
  4. jwh7April 17, 2017 at 5:46 PM

    UP is failing:
    --------------------
    kernel/sched/bfs.c: In function ‘rq_dither’:
    kernel/sched/bfs.c:903:53: error: implicit declaration of function ‘hrtick_enabled’ [-Werror=implicit-function-declaration]
    if ((rq->clock - rq->last_tick > HALF_JIFFY_NS) || hrtick_enabled(rq))
    ^~~~~~~~~~~~~~

    ReplyDelete
    Replies
    1. jwh7April 17, 2017 at 5:49 PM

      Helpful that whitespace is stripped out... :-/ The "hrtick_enabled" is highlighted.

      Delete
    2. Alfred ChenApril 18, 2017 at 7:51 PM

      @jwh7
      I have pushed a fix to git, pls check it out at https://bitbucket.org/alfredchen/linux-gc/commits/3ce1f6d3413be6bed54ffba0ec7ba85c42b54f4f

      Delete
    3. jwh7April 19, 2017 at 1:55 PM

      Up and running; NO_HZ_IDLE @100 Hz...what is your recommendation? Running fine so far; thanks Alfred!

      Delete
    4. Alfred ChenApril 19, 2017 at 11:02 PM

      @jwh7
      I don't have recommendation for UP system, as only one cpu in UP system, and it should not running in no_hz mode even the kernel config is set to NO_HZ. :)

      Delete
    5. jwh7April 21, 2017 at 12:25 PM

      I mean in general; I run a x64 system too. :-)

      Delete
  5. AnonymousApril 17, 2017 at 11:28 PM

    @Alfred,

    compiled with 4.10.10 + CONFIG_NO_HZ_FULL + CONFIG_NO_HZ_FULL_ALL. Feels ok, no issues so far after 2 days usage. There was one hang, but probably not related to kernel.

    Not sure, thou, whether tickless is ok or not or it does not matter much as nothing really changed and benchmarks does not show any improvement so far. Fedora uses tickless, there must be some idea behind, so I'll give it a try.
    Guys do You have any thoughts about 100HZ vs tickless?

    regards
    Eduardo

    ReplyDelete
    Replies
    1. Alfred ChenApril 19, 2017 at 11:28 PM

      @Eduardo
      Each option has it's own pros and cons, so I don't recommend which one to be used. But just make this option works as expected in scheduler code.
      For the no_hz_full, I have add debug code to test the tick counts of each cpu, when system is idle, non-zero cpu(1~n) have less tick counts than cpu0. IMO, this may make more power-saving. But feel free to try these options(and others) to fit for your need.

      Delete
    2. AnonymousApril 23, 2017 at 8:41 AM

      @Eduardo:
      I'm applying a simple self-made patch to use 512HZ since the months that MuQSS' 128HZ resulted in system-drivers' troubles. I've kept it, formerly for the comparability of MuQSS with VRQ, and still, as it works well for me until now.

      BR, Manuel Krause

      Delete
    3. AnonymousApril 23, 2017 at 8:49 AM

      @Eduardo:
      Forgotten to add, that I use NO_HZ_IDLE and HIGH_RES_TIMERS only. First of them was recommended by Con some months ago for non-server usage, IIRC.

      BR, Manuel Krause

      Delete
    4. jwh7April 24, 2017 at 9:11 AM

      Thanks for the reminder Manuel; I had meant to try out 256 Hz a while ago, and forgot about it. If others are wondering what this is about, see here. This wasn't carried into 4.9-ck1 though [ref: 4.9-ck1 announcement].

      Delete
    5. AnonymousApril 24, 2017 at 11:57 AM

      @jwh7: I have to thank you for enriching this topic by re-tracing and adding the sources/ reasons of my former decisions. Sometimes it's hard to keep full track of them in my own mind. ;-) And, mmh, I can't give a promise of usefulness for VRQ users. Given, that BFS/CK formerly shipped with 1000HZ recommendation for desktops and lowering it was supposed to offer more throughput and less power consumption etc. etc. YMMV.

      BR, Manuel Krause

      Delete
    6. AnonymousApril 24, 2017 at 1:01 PM

      I'm still using nohz_full, so far I do not see any drawbacks at all, laptop batterry seems to last longer, no visible lags, etc. On Phenom all is fine as well.
      On next kernel release I'll try compile kernel on tickless (have not done it yet), let's see how that fares.

      Btw, I have got myself a Ryzen :) No mobo and ram yet, but that must arrive soon. So testing party is imminent :)

      Regards, Eduardo

      Delete
    7. AnonymousApril 24, 2017 at 1:33 PM

      Oh yes, now I remember a bit more clearly: Con had written of possible micro-optimisations with a HZ value being a power of 2 vs. 10 (kernel default). And my testing in these times showed 512 as the lowest possible to avoid a kernel complaint about a hrtimer frequency mismatch with power of 2 HZ values (kernel's typical values had been failureless). Also, in these times, values of 100HZ/ 128HZ, degraded interactivity with MuQSS.
      Con abandoned this power of 2 approach like he writes in jwh7's citation.
      I haven't retested this HZ thing after doubling my RAM. ATM I'm glad @512.

      BR, Manuel Krause

      Delete
    8. AnonymousApril 24, 2017 at 1:50 PM

      @Eduardo:
      I get a little jealous now. And...
      Maybe you'd not need a high-performance cpu scheduler like VRQ in future any more.
      Please, Eduardo, stay with us! :-)

      BR, Manuel Krause

      Delete
    9. Alfred ChenApril 24, 2017 at 7:43 PM

      @Edurado
      Pls try VRQ on your new Ryzen and see if you have similar issue reported by Dzon?
      I wonder Dzon's issue is caused by his kernel config, but currently short of time to find it out.
      Busying sync up mainline scheduler code change of v4.11, 3k+ LOC changes. But good news is the first 4.11-rc6 kernel with VRQ is up and running over night. Bad news is it will be frozen after resume from suspend, and still a few sync up issue needed to be handled, :)

      Delete
    10. AnonymousApril 25, 2017 at 1:10 AM

      @Alfred
      I'm starting to suspect the kernel config, too. If I have time, I will try to install something standard like ubuntu and try the tests there. But this problem happens only with VRQ, not with CFS or MUQSS with the same config and build enviroment. So I'm all for narrowing the culprit down. Also, as I mentioned in last email report, the vrq-095 is behaving a little bit better. Ryzen result is even better, while still having this problem.

      12:24.01elapsed 1173%CPU on cfs versus
      15:45.96elapsed 756%CPU on vrq (26% longer time)

      In comparison vrq-094 on i7-920 took 72% longer time while vrq-095 45%.
      Thanks for the news on sync up progress.

      Regards,Dzon.

      Delete
    11. AnonymousApril 27, 2017 at 6:19 AM

      @Manuel,
      I'm not going anywhere, I'll still be (most likely) using VRQ as my main kernel, just builds will finish faster, quite faster I imagine :)

      I finally have got MOBO and RAM for my Ryzen build. Now, some time this / next week I'll run some tests on Ryzen, I'll probably will be comparing those to Phenom II 975BE and Phenom 9950BE (where it makes sense).
      Busy testing week is coming :)

      regards
      Eduardo

      Delete
    12. AnonymousApril 27, 2017 at 7:45 AM

      @Eduardo:
      I really didn't want to kid you.
      Please, enjoy the Ryzen testing party, at best with your friends. Recently I've participated in such a party for a new GFX card @a friend with Windows. That evening was so much fun!

      BR, Manuel Krause

      Delete
  6. 幻影火April 22, 2017 at 4:32 PM

    trying vrq, the latest BFQ and MuQSS is all give me crash at latest 4.10.12 and 4.10.11

    ReplyDelete
    Replies
    1. AnonymousApril 23, 2017 at 8:18 AM

      Can you, please, provide more details?
      System, drivers etc.?

      My kernel 4.10.12, with most recent BFQ v8r10 I/O scheduler together with VRQ 0.95 from Alfred compiles and works very well.

      Can it even be that you're patching in a wrong way? Maybe wrong base vanilla kernel, and wrong patches added? Have a look on the patch and compile output.

      BR, Manuel Krause

      Delete
  7. Alfred ChenApril 27, 2017 at 1:32 AM

    @all
    For the kernel 4.11, it may be released next week, but I will be out of town for holiday and not able to access to internet. So I have uploaded an all-in-one patch at https://bitbucket.org/alfredchen/linux-gc/downloads/v4.11_vrq095a.patch , you can take it as a pre-release of VRQ for v4.11.

    Please be noticed that the frozen after resume issue remains and similar issue happens even in mainline kernel(without VRQ), tested on v4.11-rc7(issue remains in rc8 with VRQ).

    Regard the above issue, the VRQ kernel runs fine as expected.

    Enjoy fun with 4.11

    BR Alfred

    ReplyDelete
    Replies
    1. AnonymousApril 27, 2017 at 5:16 AM

      Thanks. I will test later today.

      Regards, Dzon.

      Delete
    2. AnonymousApril 27, 2017 at 7:24 AM

      @Alfred:
      Please, let us know, when you'd be back. I dunno in which place the resume issue has to be fixed (kernel/ VRQ), but without working suspend/ resume I'm refusing to test it anyways. I depend on it working.

      BR, Manuel Krause

      Delete
  8. AnonymousMay 15, 2017 at 12:41 AM

    @Alfred,

    if You remember, couple of times I have reported an issue when with VRQ (and cpufreq) CPU does not scale frequency anymore, so I have encountered it again.
    Using 4.10.15 (this time it's pstate) VRQ using full tickless, CPU does not scale up when in "powersave", it's always on min frequency. When I change to "performance" mode, in i7z it shows 3.1ish GHz which is fine, but system is slow anyways. In addition to that /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq always shows half of what i7z shows :) That's strange.
    In addition I don't think this is related to full tickless as I had this before VRQ was able to use full tickless

    I have not encountered this on any other kernels, just VRQ, but since I mostly use VRQ, I can not rule out problem with mainline code.

    I write here as I'm not yet on 4.11, but will be soon :)

    BR, Eduardo

    ReplyDelete
    Replies
    1. AnonymousJune 13, 2017 at 11:14 PM

      @Alfred,

      VRQ has nothing to do with the slowdown and frequency scaling, now I finally, for the first time tho, got to the situation that Ubuntu mainline kernel does the same, after suspend computer is slow and frequency will NOT go up automatically.
      I suspect BIOS or Dell issue.

      So, if You, after my reports, considered this a VRQ issue, I'm glad to report, You can disregard that issue being VRQ problem.

      Br, Eduardo

      Delete

Subscribe to: Post Comments (Atom)