Sunday, June 7, 2020

BMQ v5.7-r1 release

BMQ v5.7-r1 is released with the following changes

1. Fixes for two compilation issue in r0 release.

Nothing new, just a bug fix release before project-C.

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

Bug report at https://gitlab.com/alfredchen/bmq/issues

4 comments:

  1. Thank you very much.

    ReplyDelete
  2. Running great on Ryzen@home and i7@work. Thanks!

    I have a question, though. Now it's +/- 4 boost for tasks, theoretically I can change that in code to be +/- 8 or whatever.
    Is 4 optimal or how did You determine that 4 is the right boost? Is it meaningful to try other boost range at all?

    BR, Eduardo

    ReplyDelete
    Replies
    1. Sure you can, it's defined at https://gitlab.com/alfredchen/linux-bmq/-/blob/linux-5.7.y-bmq/include/linux/sched/prio.h#L31

      As for choosing 4 as the right boost - it's what Google chose for their initial scheduler design for their zicron kernel, on which BMQ is based on.

      It was originally defined at : https://fuchsia.googlesource.com/fuchsia/+/74abecafd00cd91b953a42903732ad856ec0736a/zircon/kernel/kernel/legacy_scheduler.cc#34

      And dynamic priorities were introduced in the commit : https://fuchsia.googlesource.com/fuchsia/+/c19b04a71e3a78a7b5a235690c85721dc4aea80b which doesn't really explain the rationale behind it.

      But would still like an explanation by the man himself!

      -P

      Delete
    2. +/- 4 boost prio is kept in BMQ b/c the time slice duration.
      Time slice is default 4ms in BMQ, in BMQ, boost prio happens in condition when task run time is less than a threshold(time slice shift some bits).
      If there are +/- 8 boost prio, there will be 16 levels will need to be distinguished. 4ms >> 16 = 64ns. It's unlikely a reasonable duration(too too short) tasks will spend.

      Delete