Matthias Kohler announced this "Multiple run-queues for BFS" scheduler to the kernel developers' list. "I'm doing a CPU-Scheduler based on BFS by Con Kolivas with support for multiple run-queues. BFS in itself uses only one run-queue for all CPU's. This avoids the load-balancing overhead, but does not scale well. One run-queue per CPU does scale well, but then the scheduler has load-balancing overhead. The scheduler I'm developing supports every possible run-queues configuration. You can have one single run-queue like in BFS, or you can have one run-queue per CPU, or something completely different like one run-queue every two CPU's. This, in theory would allow the scheduler to be fine-tuned to the hardware and the workload."
Before getting too excited, this scheduler is far from being in a state where it stands any chance of being merged into the mainline Linux kernel. Right now the new scheduler is very unstable to a point that the scheduler's author isn't even providing benchmark results since the tests can't complete nicely.
This revised BFS scheduler will allow users to easily change the run-queue layout. "To optimize the scheduler to specific hardware and workloads. You could use one run-queue for all CPU's if you want low latency and low scheduling overhead. You could use one run-queue per CPU if you want high scalability. You could use one run-queue per n CPU's is these n CPU's share cache and there is not much benefit in load balancing between them."
Aside from being more scalable than BFS, it ultimately could end up having all of the features of the Brain Fuck Scheduler as well as CFS, the mainline Completely Fair Scheduler. The developer says "especialy throughput and low latency" where it would match the features. A benefit is that as of right now the scheduler is far less lines of code than CFS.
For more details and an early patch of this scheduler that applies against the Linux 3.6 kernel, see the aforelinked mailing list announcement.