Re: Soon committing the "256-queue runqueue" scheduler work

On Fri, 6 Jun 2025, Olivier Certner wrote:

Bonjour Olivier,

>> Can you tell us the 'why?' as well, as what this work is trying to
>> solve/improve?  I am sure there was a reason to do all this?
>
> This was really to have this working:
> "- The 32 realtime priority levels, and the 32 idle priority ones, are now going to be really distinct.  Previously, levels with the same quotient when divided by 4 were aliased (separately in each class)."
> for practical uses (I use idprio abundantly, e.g., for background compilation and other jobs) and for POSIX compliance, as software that wants to use real-time scheduling (generally for multimedia) expects the levels to be distinct (they generally choose one level, either hardcoded or obtained through sched_get_priority_min()/sched_get_priority_max(), and then increment/decrement from it, expecting that highest priorities will preempt lower ones, which they would not here; the problem is mitigated with enough cores depending on the software).  We would like to promote the use of soft real-time software on FreeBSD, and in particular audio/video real-time processing.
>
> Another, longer-term reason was to get familiar with ULE and gather knowledge on where it works well, where it does not, and in which ways it could be extended (or perhaps even substantially reworked) for the future.  In the process, some of the thread selection algorithms used have been fused and their performance in corner cases improved.  Removing duplicate or very similar code both allowed to remove some bugs or quirks without positive effects and improve the overall understanding.

Thank you so much for the longer explanation (and the work)!

/bz

-- 
Bjoern A. Zeeb                                                     r15:7