[GSoC 2026] Custom scheduler implementation

Development OS
1

Hi everyone,
I am a second year (ending) CS Major student with a lot of interest in algorithms, optimisation, and OS level work.

I’m considering submitting a self-proposed project for GSoC 2026: implementing a custom CPU scheduler for Haiku called DPS (Democratic Process Scheduler).

The core idea is that instead of treating scheduling decisions as purely individual, DPS lets tasks vote for each other based on observed inter-task relationships — waker identity, burst patterns, and reinforcement-learned preferences that persist across process lifetimes. Short-burst latency-sensitive tasks get classified as “institutions” and bypass the election entirely for fast dispatch. The goal is better system responsiveness for structured workloads like desktop pipelines and game loops.

I’ve already implemented this on Linux under the sched_ext framework (merged in 6.12) and benchmarked it against BORE, scx_bore, scx_bpfland, scx_flash, and scx_rusty. The headline results on a 4-core Haswell: schbench p50 wakeup latency of 10 µs vs 152 µs for BORE, p90 of 43 µs vs 1942 µs, and significantly better worst-case RT latency on cyclictest. The tradeoff is ~11% lower throughput on embarrassingly parallel CPU workloads with no inter-task structure, which is expected.

The GSoC project would involve porting this logic from sched_ext to Haiku’s native scheduler framework — adapting the preference learning and dispatch tiers to Haiku’s thread/team model and benchmarking against the current affine scheduler. It’s a substantial scope, but having a working reference implementation should make the design decisions concrete rather than speculative.

A few things I’d genuinely appreciate guidance on:

  • Is the Haiku scheduler architecture documented anywhere beyond the source? I’ve been reading through the kernel source but would love pointers to any design docs.

  • Are there mentors with scheduler/kernel experience who’d be interested in this kind of project?

  • Any known limitations or constraints in Haiku’s current scheduler I should be aware of before writing the full proposal?

Thanks in advance, and please, do tell if this isn’t at the top priority.
It would seem attaching links led to the post being hidden, so I won’t be attaching them.

7 Likes
2

This sounds interesting to me, note that I am not part of GSoC management for Haiku. Do you have more details?

3

You can join the mentor team if you want. Let me know and I’ll send you an invite

4

I’ll think about it..

5

I am still not as heavily experienced in programming as such as your average kernel or low level developer, but my strong points are algorithms and designing. The idea for my scheduler, is allowing processes to vote for who gave them the most advantage of getting closer to the CPU. If, a certain process gets the CPU, each process checks, since the last time I got the CPU + the last winner’s burst time, has this metric reduced since the last time I calculated the same thing? If yes, it has reduced, that means this last winner genuinely helped me getting close to the CPU, and hence puts in a vote for this.
TLDR, processes vote, winner gets a vtime boost and gets to be earlier in the queue. However, this preference built by processes is done across runs, not immediately, since it takes time to build one.
Moreover, most of the processes are short lived on the desktop, so, my scheduler also introduces three different queues- one for holding elections, where long lived tasks stay, another is a fallback queue, and the other is the RL queue.
Every time a task finishes running, the next task to be scheduled asks: “did things get better or worse for me since that PID ran?” If better, that PID gets a positive score in my preference table (+3). If worse, negative (-1). Over several runs, each task builds a ranked list of PIDs it “prefers.” When a task finishes its timeslice, it casts a weighted vote for its top-preferred PID. When a task is about to be enqueued, it collects all accumulated votes and converts them into a scheduling priority boost. No votes = penalty.

Short-burst tasks (institutions) skip the election queue for speed but still participate in voting. Learned preferences persist across process lifetimes via commstate, so new threads inherit relationships from previous threads with the same name. RL queue is pure FIFO, priority based, no elections.

As of now, I have developed the above algorithm into a workable prototype in the sched-ext framework, but I would like to further see if I can hook into the actual kernel, and I believe, Haiku would be a great place to do it, since it’s still relatively new, and the structure won’t be as complex for me also to understand it. Just my piece.

1 Like
6

I can’t offer much on Haiku kernel info other than these blog posts: https://www.haiku-os.org/blog/paweł\_dziepak .
Probably best to just experiment with building and running Haiku if you are interested and see if you think it can be done.

7

Thank you, I will, I plan to look at the source code tomorrow, and also write a proposal based on this. I will post a proposal draft on this by tomorrow, for further revisions, if required.

8

So, I have read the src code over the top, under the scheduler directory, and from what I understand, that the current implementation seems to be a pure priority based scheduler that seems give penalties to processes that take full quantums? However, I have also noticed that there seems to be also a way to add a scheduling mode, where I can see a low latency mode and power saving mode. I think perhaps for GSoC I could try implementing my scheduler as another mode before implementing it fully across the board. I would like to know if I am correct, because this seems more doable within the timeframe as I had initially thought.

9

If I remember correctly, the main advantage of the current scheduler is an algorithmic complexity of O(1). That means, the task switching time does not depend on the number of running tasks. Basically, everything is done in advance and when the time comes to switch tasks, the scheduler can simply pick the next task from the top of the data structure and start running it.

This is a valuable design idea, because there are a lot of context switches. We don’t want to spend more time picking the perfect process to run, than actually running it.

Pawel’s posts will surely help understand his work on the current scheduler in more detail.

10

Could you point me to the correct posts? The link provided by tqh seems to be broken. I plan to benchmark haiku’s current scheduler against mine under the sched-ext framework ( I shall try to make a one-one copy of it to the best of my ability), and share the results here. Perhaps that can be a good entry point for allowing Haiku to perhaps have a diversity of a scheduler family to choose from.

11

Copying the Haiku scheduler into the Linux kernel won’t be a very good test, because Haiku as a whole behaves very differently than Linux in terms of locking and things like that which affect what there is to schedule; and also the thread prioritization scheme as well. You should instead try to come up with a benchmark that runs in userspace and tries to measure various kinds of latency, and test it on both Linux and Haiku.

12

There was an extra backslash or some urlencoding problem in the link, this should work: Paweł Dziepak's blog | Haiku Project

13

I assumed that would be the issue, yes. Are there pre existing tools perhaps in buildtools for benchmarking? Or perhaps there are none and have to be written? Would that be considered a valid proposal then? Creating benchmark scripts that measures both from my scheduler and the currently implement scheduler? If so, I would gladly begin writing up the proposal lay the groundworks for it.

14

I don’t think just benchmark scripts would be enough for a GSoC project.

I don’t think we have too many proper test for the scheduler performance, and it could be interesting to write some. But there may be some made for other operating systems, or portable ones that we could use on Haiku. Have you looked into that, or used any yourself?

15

Linux has the following- schbench, hackbench, sysbench, and cyclictest which are all benchmark tools meant to test system performance under load vs clean, as well as wakeup latencies. I will give their links down here, because these are the tests I used for my own benchmarking against the other sched-ext schedulers. Perhaps we can port this over to comply with Haiku’s POSIX code and check the benchmarks?

All the above benchmarks do what we want and some more. I think it’d be pretty interesting to port them over to Haiku. And, my proposal was not just to perhaps write them/port them, but also to implement my own scheduler in the system and run the said benchmarks to compare numbers.

The proposal would therefore be: port these benchmarking tools to Haiku, implement DPS as a third scheduling mode, and use the ported tools to compare DPS against the existing scheduler directly on Haiku.
I have attached two links above, since that seems to be the maximum, I will attach the rest in the next reply.

17

Linux has the following- schbench, hackbench, sysbench, and cyclictest which are all benchmark tools meant to test system performance under load vs clean, as well as wakeup latencies. I will give their links down here, because these are the tests I used for my own benchmarking against the other sched-ext schedulers. Perhaps we can port this over to comply with Haiku’s POSIX code and check the benchmarks?
All the above benchmarks do what we want and some more. I think it’d be pretty interesting to port them over to Haiku. And, my proposal was not just to perhaps write them/port them, but also to implement my own scheduler in the system and run the said benchmarks to compare numbers.

The proposal would therefore be: port these benchmarking tools to Haiku, implement DPS as a third scheduling mode, and use the ported tools to compare DPS against the existing scheduler directly on Haiku. Because, the tools alone will be a great addition for when Haiku decides to further improve the OS, these tools will definitely help in benchmarking. I can’t seem to post links to the githubs, but these are the best tools I know.

18

I have attached a draft proposal below, please do let me know if there’s any changes to be made, of if the proposal has to be changed. I think the issues I have taken are very much doable in the timeframe provided for GSoC.

20

image
image1225×766 121 KB

Some good news, I managed to get a version of hackbench working on haiku. However, since the RAM and core count had to be limited because of the VM, I could only bring the task count till here. I might consider this as a commit to be submitted for the GSoC, please do let me know what the team thinks of it

21

VMs are not good for benchmarking things like schedulers; interrupts and other latency on VMs is radically higher than it is on bare metal. Having a port sounds nice, though.

22

Yes, however, I own only one system, and compiling this was a trip by itself. I am sure someone with haiku running on full hardware will be able to get a more reliable result. Just for information, the screenshot attached above is from an i3 4th gen processor, and I had given the VM 2 threads and 2GB of RAM to work with, and this was run on QEMU.