Wednesday, April 10, 2019

BMQ 0.92 is release

BMQ 0.92 is released with the following changes

1. Rework boost/deboost task and thresholds.
2. Rework yield(). By introducing skip task in rq structure and skip schedule it in __schedule(). This should fulfilled the response to yield() and the long existed yield problem should be fixed.

This is yet another improvement release of BMQ. There are other bug fixes/improvement on going but ready to be released.

Enjoy BMQ 0.92 for v5.0 kernel, :)

Full kernel tree repository can be found at https://gitlab.com/alfredchen/linux-bmq
And all-in-one patch can be found at gitlab.

Please report bugs at https://gitlab.com/alfredchen/bmq/issues.

NOTICE:
Some untested code are stealth in the yield() rework commit, emergency fix at 

https://gitlab.com/alfredchen/linux-bmq/commit/1b66bf997e19f3fa59e0871cce0de4778e91bce3

27 comments:

  1. up and running on 2 machines no problems so far.

    ReplyDelete
    Replies
    1. Atleast with intel graphics opengl seems to be broken. I get strange hangs. I will check if this is related to the yield changes by reverting.

      Delete
  2. Reverting back to 0.91 helped no more hangs.

    ReplyDelete
    Replies
    1. Pls check with mainline CFS, will provide further improvement patch based on the feedback.

      Delete
    2. CFS was fine but your yield revert patch fixed the problem.

      Delete
    3. "yield revert patch" means https://gitlab.com/alfredchen/linux-bmq/commit/1b66bf997e19f3fa59e0871cce0de4778e91bce3 ?

      Delete
  3. Does this mean /proc/sys/kernel/yield_type=2 is supported, or a fixed/improved yield_type=1?

    ReplyDelete
    Replies
    1. Current, it replaces previous yield_type=1. May revert back the original yield_type 1 implementation and implement this as yield_type=2.

      Delete
  4. hi Alfred!, i have problem, when i starting apps ncmpcpp, gedit, my system freezes for 30~60 seconds, with yield_type=1/2.

    yield_type=0 fixed this issue, i know yield_type=0 not recommended for using.

    *waiting fix*

    ReplyDelete
  5. on bmq091+patch system works great! (amd ryzen 5 2600)

    ReplyDelete
  6. For those who have issue with BMQ092. Please read the NOTICE at the tail of post and apply the emergency patch.

    ReplyDelete
  7. Is it possible to adapt BMQ to the 4.19? I would have to backported pressure stall information or something else? Is this a difficult task?

    ReplyDelete
    Replies
    1. Sorry. My bandwidth is limited, so I can't commit any LTS kernel backport.

      Delete
  8. @Alfred,
    I tried playing D3 on BMQ - heavy stutters with tickless idle and full tickless.
    Hopefully this will be taken care of later down the road :)
    Thanks.
    BR, Eduardo

    ReplyDelete
    Replies
    1. @Eduardo
      Does D3 on wine relate to yield() code change? I have worked on stutter issue, but I'd like to confirm yield code changes before focusing on the others.

      Delete
    2. @Alfred,
      If I remember correctly, 0.91 worked w/o issues, 0.92 stutters. I tried running KVM virtualization on 0.92 it as well, stutters like in D3.
      P.S. I don't play D3 at all these days, I just test schedulers on it, because of good test case :)
      BR, Eduardo

      Delete
    3. @Alfred,
      I did an experiment - I reverted all yield related commits, that is fix and rework. Compiled with full tickless (did not have time for tickless idle, but I reckon it doesn't matter much in this case) and stutter is gone from D3 :)
      So the culprit was new yielr code.
      BR, Eduardo

      Delete
    4. Would you pls list which commits you had reverted?

      Delete
  9. I reverted these commits in this order:
    1. 1b66bf99
    2. 3ecf5a12
    BR, Eduardo

    ReplyDelete
    Replies
    1. Have you tried yield_type = 0?

      Delete
    2. Not, I haven't, I don't play with yield_type anymore :) I'll try at some point, if You suggest so.
      BR, Eduardo

      Delete
  10. @Alfred and all other people on here:
    I have this one running for now 5 1/2 days with nightly hibernations.
    Today I've made a severe experience that reminds me of pre-PDS days, that making heavy use of a /dev/shm that is backed by swap space heavily impacts whole system usability.

    Notes:
    (1) The /dev/shm never reached it's max. content vs. size, but I had to process many files (decode-to, edit, decode-back, delete) today. Suddenly the system starved for about 15 minutes, but then it came back. No errors logged.
    (2) I haven't noticed this with PDS, but maybe the hibernation cycles there haven't been stable enough to allow 5 1/2 days of uptime to show up this memory-aging(?) effect.
    (3) I also store the Firefox Cache on /dev/shm and this is normally the first application to stall at first and then notify about failing script(s) execution via popup.

    Anyway, can someone of you, please, tell me how I can safely calm down the swapping processes somehow?
    Should I use "nice" or some other method?

    Many thanks in advance,
    Manuel

    ReplyDelete
  11. Another tool to test schedulers in "gaming" workflow. The script is used to test/improve VariableRefreshRate implementations and also to visual research. github.com/kleinerm/VRRTestPlots

    ReplyDelete
  12. @Alfred:
    Today I've seen your recent commits regarding BMQ v0.93 and the all-in-one patch in your gitlab repositories.

    Are they ready to use or is there any reason to hold back an announcement?

    Best regards,

    Manuel

    ReplyDelete
    Replies
    1. Just too busy to publish the announcement at that time.

      Delete