On Wed, May 15, 2019 at 09:05:32AM -0500, Amit Kulkarni wrote: > > This diff survived multiple tens of kernel builds, a bsd.sp build, > bsd.rd build, a bsd.mp without these changes, userland/xenocara, a > make regress a few days ago all on 3 desktops on amd64. Ran under > all possible scenarios listed in previous sentence. No major > invasive changes attempted, all tools should work as is, if its > broken, please let me know. This is faster than current, but not > sure by how much, placebo effect in play.
CPU-bound processes (builds) run at the same priorority so both the current and the proposed algorithms should split them in equal time slices resulting in the same behavior. > > Not sure if the reduction from 32 queues to a single TAILQ would be > accepted, but tried it anyway, it is definitely faster. This code > tries to reduce the complexity in deciding which queue to place the > proc on. The intent of using multiple queues is to allow to wakeup processes and to make them runnable with the desired priority. To achieve this with a single queue, this would require to insert the process to wake up in the "middle" of the TAILQ. This is not a problem as there are only few runnable processes on a typical system. Example, on a single CPU machine, suppose a CPU-bound process is running (ex. gzip compressing a file), we want any I/O-bound processes (ex. audio player) that wakes up to be inserted on the run queue before the CPU-bound process.
