But seriously, it does really bug me on principle that DropBox should use over half a GB simply because it uses Chromium, even when nothing is visible.
OP here. this is a cursed project lol, but i wanted to see: What happens if you replace the OS scheduler with an LLM?
With Groq speed (Llama 3 @ 800t/s), inference is finally fast enough to be in the system loop.
i built this TUI to monitor my process tree. instead of just showing CPU %, it checks the context (parent process, disk I/O) to decide if a process is compiling code or bloatware. It roasts, throttles, or kills based on that.
Its my experiment in "Intelligent Kernels" how they would be. i used Delta Caching to keep overhead low.
oh absolutely. burning a coal plant to decide if i should close discord is peak 2025 energy.
strictly speaking, using the local model (Ollama) is 'free' in terms of watts since my laptop is on anyway, but yeah, if the inefficiency is the art, I'm the artist.
you are technically right (the best kind of right). i am running in userspace, so i cant replace the actual thread scheduling logic in Ring 0 without writing a driver and BSODing my machine.
think of this more as a High-Level Governor. The NTOS scheduler decides which thread runs next, but this LLM decides if that process deserves to exist at all.
basically; NTOS tries to be fair to every process. BrainKernel overrides that fairness with judgment. if i suspend a process, i have effectively vetoed the scheduler.
This is a super simplification of the NTOS scheduler. It's not that dumb!
> if i suspend a process, i have effectively vetoed the scheduler.
I mean, I suppose? It's the NTOS scheduler doing the suspension. It's like changing the priority level -- sure, you can do it, but it's generally to your detriment outside of corner cases.
Interesting experiment. Scheduling decisions feel like the place where unpredictability shows up first. Curious how you reason about rollback when the scheduler makes a bad call.
Great point. In a real kernel, non determinism is a bug. Here, it's a feature (or at least, a known hazard).
To answer your question: There is no Ctrl+Z for SIGKILL. Once the LLM decides to kill a process, it's gone.
My reasoning for 'rollback' is actually latency. I built in a 'Roasting Phase' where the agent mocks the process for a few seconds before executing the kill. That delay acts as an optimistic lock it gives me a window to veto the decision if I see it targeting something critical.
If I'm AFK and it kills my IDE? I treat that as the system telling me to touch grass.
This is a pretty funny project, you've outsourced the neurotic developers that keep their task manager open and kill off processes they don't like.
I wouldn't call it replacing the scheduler though - more that you've made a scheduler manager.
haha exactly. i realized i spent too much time staring at htop wondering what is this process?, so i decided to automate my own anxiety.
Scheduler Manager is definitely the more accurate term. Im just the middleman between the chaos and the kernel.
I resemble that comment!
But seriously, it does really bug me on principle that DropBox should use over half a GB simply because it uses Chromium, even when nothing is visible.
OP here. this is a cursed project lol, but i wanted to see: What happens if you replace the OS scheduler with an LLM?
With Groq speed (Llama 3 @ 800t/s), inference is finally fast enough to be in the system loop.
i built this TUI to monitor my process tree. instead of just showing CPU %, it checks the context (parent process, disk I/O) to decide if a process is compiling code or bloatware. It roasts, throttles, or kills based on that.
Its my experiment in "Intelligent Kernels" how they would be. i used Delta Caching to keep overhead low.
It really is cursed to be spending hundreds of watts of power in a datacenter somewhere to make a laptop run slightly faster.
oh absolutely. burning a coal plant to decide if i should close discord is peak 2025 energy. strictly speaking, using the local model (Ollama) is 'free' in terms of watts since my laptop is on anyway, but yeah, if the inefficiency is the art, I'm the artist.
> using the local model (Ollama) is 'free' in terms of watts since my laptop is on anyway
Now that’s a cursed take on power efficency
efficiency is just a mindset. if i save 3 seconds of my own attention by burning 300 watts of gpu, the math works out in my favor!
You can't replace the NTOS scheduler. This is more of an automated (?) process manager.
you are technically right (the best kind of right). i am running in userspace, so i cant replace the actual thread scheduling logic in Ring 0 without writing a driver and BSODing my machine.
think of this more as a High-Level Governor. The NTOS scheduler decides which thread runs next, but this LLM decides if that process deserves to exist at all.
basically; NTOS tries to be fair to every process. BrainKernel overrides that fairness with judgment. if i suspend a process, i have effectively vetoed the scheduler.
> NTOS tries to be fair to every process
This is a super simplification of the NTOS scheduler. It's not that dumb!
> if i suspend a process, i have effectively vetoed the scheduler.
I mean, I suppose? It's the NTOS scheduler doing the suspension. It's like changing the priority level -- sure, you can do it, but it's generally to your detriment outside of corner cases.
Interesting experiment. Scheduling decisions feel like the place where unpredictability shows up first. Curious how you reason about rollback when the scheduler makes a bad call.
Great point. In a real kernel, non determinism is a bug. Here, it's a feature (or at least, a known hazard). To answer your question: There is no Ctrl+Z for SIGKILL. Once the LLM decides to kill a process, it's gone. My reasoning for 'rollback' is actually latency. I built in a 'Roasting Phase' where the agent mocks the process for a few seconds before executing the kill. That delay acts as an optimistic lock it gives me a window to veto the decision if I see it targeting something critical.
If I'm AFK and it kills my IDE? I treat that as the system telling me to touch grass.