Tuesday, April 30, 2019

BMQ 0.93 release

BMQ 0.93 is released with the following changes

1. New tasks has MAX_PRIORITY_ADJ boost_prio. This will help with task fairness while new task boost creating.
2. Rework deboost_task(). Again, this will help to reduce scheduling overhead.
3. Re-implement yield_type 1. The new yield implement now can be set by yield_type 2. Still, default is 1(deboost task and requeue it).

This should be the last BMQ release for v5.0 kernel.

Enjoy BMQ 0.93 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.

7 comments:

  1. Thanks for the release. Up and running on 4 machines with no problems so far.

    ReplyDelete
  2. Compiled and working fine for good 3 days on i7@work (I took patch a day before even before You wrote about it :)). This time I went for full tickless, i7@work 250Hz+nohz_full on Ryzen@home 100Hz+nohz_full.

    Sound crackling seems to be gone, but I have occasional bigger sound "stops" (for half a second and sometimes even 2 secs) when something is going on, I haven't figured it out yet what exactly causes this, but I have suspicion on IO activity. I'll try to monitor that when that happens again.

    On Ryzen performance seems to be great, at least with some tests with gaming it shows great performance, if something odd will happen, I'll report a bug or ask here.

    Thanks Alfred!

    BR, Eduardo

    ReplyDelete
    Replies
    1. @Eduardo:
      Thank you for your report!
      Do you consider your results being dependent on the recent yield_type changes? Unfortunately, I have no reliable load test scenario to compare for those changes, in particular regarding sound stuttering. And I was and still am quite curious if you would be able to do such a comparison within your default testing runs.
      For some reason I had put yield_type = 2 into a startup script at my nvidia times, years ago, definitely not needed any more but still kept.
      As yield_type = 1 makes a difference in code now, compared to earlier BMQ versions, what effects does it have in real life?

      Don't misunderstand me, all on here is working very well with BMQ 0.93.

      Best regards and thanks to all participants and to Alfred for his thoughtful and well-operating rework of his former PDS,

      Manuel

      Delete
    2. I did some brief testing with this BMQ 0.93, and some wine gaming. I tested with yield_type=2 first, and found something kinda like described above. At times there would be a quick .5-1 sec "stutter/lockup" before things caught up.
      Setting yield_type=1 did not seem to cause the same problems.
      I tested this with 1000HZ and NO_HZ_IDLE, and not NO_HZ_FULL tho, as i have had some iffy experiences with that before for some reason. Not really sure a full tickless kernel is the best suited for a scheduler?

      I have no such problems with yield_type=2 and MuQSS tho, but i guess the functions are far from "the same" in that respect.

      Performance is still a wee tiny smidge lower with BMQ vs. -ck patchset.

      Delete
    3. For the yield_type, I just hope the yield_type 0, 1, 2 can satisfy all users. But keep in mind that yield type is not comparable between schedulers and the behaviors under different scheduler would be different too.

      For BMQ scheduler, there will be no big changes in my list, so just implement level improvement can be expected in the incoming releases.

      Delete
  3. Hi Alfred,
    Do you plan to reintroduce the expected behavior for the IDLE scheduling class?
    Thanks.

    ReplyDelete
    Replies
    1. No. does an IDLE scheduling class at nice level 19 works for you?

      Delete