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
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
Thank you very much.
ReplyDeleteRunning great on Ryzen@home and i7@work. Thanks!
ReplyDeleteI 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
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
DeleteAs 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
+/- 4 boost prio is kept in BMQ b/c the time slice duration.
DeleteTime 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.