Shouldn't this be in userspace?

Posted Feb 7, 2026 14:28 UTC (Sat) by RazeLighter777 (subscriber, #130021)
Parent article: An in-kernel machine-learning library

I'm unsure what this patch is designed to do that can't be done from userspace and existing kernel interfaces. Most data related to subsystems can be collected through eBPF hooks / audit subsystem. And policy / tuning can be pushed through eBPF programs and maps, as well as sysfs parameters.

The wording on it's purpose is unclear, but it seems the general idea is to provide ML models with internal kernel data and the ability to alter kernel policy. It's unclear why an ML-specific mechanism is needed.

I expect this series will be met with skepticism, and the author needs to meet a high hurdle to justify inclusion when existing kernel mechanisms exist for much of the proposed features.

(The wording makes me initially suspicipus of this series being AI generated)

I'll give the code a read and post my thoughts in a bit.

to post comments

Shouldn't this be in userspace?

Posted Feb 7, 2026 15:03 UTC (Sat) by RazeLighter777 (subscriber, #130021) [Link] (1 responses)

I gave it a read.

The subsystem appears to introduce a sysfs interface, which revolves around a character device that can be read from/written to via user/kernel space. It implements a number of operations that allow initializing the interface, attaching it to subsystems, and clearing the dataset, as well as setting a couple "modes" for the device that inform policy on how the "recommendations" are intended to be used. It looks like there is a notification mechanism for passing events from kernel space as well, for what looks like triggering backpropagation.

1) The patch's documentation is missing/poor. Many of the constants are undocumented, and there are no additons to Documentation/.

2) I don't see any kernel selftests, kunit or otherwise, to test correctness of the series.

3) While I see a "test driver" interface being added to lib/ the code lacks any example implementation of an existing kernel subsystem pushing data to be used by this series. So while you might be able to create and instatiate an interface, I don't see any actual implementation from the individual subsystems to actually provide data for the model. So this series is missing that critical piece.

4) The author needs to specifically address why this belongs in kernel space and can't be implemented through existing means.

Overall, I think this series is unsuitable in the current state, and raises architectural questions that need anwering before any serious consideration. I think that it's difficult to justify an ML specific interface for driving kernel policy when well-tested, existing mechanisms exist for reading kernel logs and events and pushing policy (audit subsystem / ebpf programs and hooks).

Whether this is AI generated or not, I'm 50/50. The code looks *vaguely* correct to me, but the wording is a little circular and unclear, so it's entirely possible. I'm not super optimistic at this point about it.

Shouldn't this be in userspace?

Posted Feb 8, 2026 5:06 UTC (Sun) by adobriyan (subscriber, #30858) [Link]

> 2) I don't see any kernel selftests, kunit or otherwise, to test correctness of the series.

As much as I don't like this patch, it doesn't do anything yet, there is nothing to test.

Shouldn't this be in userspace?

Posted Feb 7, 2026 18:38 UTC (Sat) by ATLief (subscriber, #166135) [Link] (4 responses)

I think a good candidate for this would be the kernel’s performance scaling subsystems. The default performance governor (“schedutil”) uses tons of manually configured heuristics to predict what hardware parameters would be “best” for power efficiency and performance, but there are so many possible combinations of sensor readings, workloads, and interpretations of “best”.

The only way you’d be able to effectively address all of those scenarios would be with something ML-based. Both AMD and Intel CPUs support setting their own “best” hardware parameters and the kernel enables that by default; our hardware is already using ML to decide on hardware parameters, it’s just that the kernel has very little influence on it.

I don’t think eBPF is well-suited for ML, so any such solution would probably require manual heuristics anyway. I’m not aware of any ML-based solutions in userspace, either. That’s probably because any userspace application would have to fetch so many parameters from the kernel that such an application would only make sense being within the kernel itself.

Shouldn't this be in userspace?

Posted Feb 8, 2026 1:27 UTC (Sun) by quotemstr (subscriber, #45331) [Link] (3 responses)

There are tons and tons of great places to apply AI in Linux. Every magic number (my favorite being the "I determined this by opening LibreOffice a bunch of times" one) is a candidate for some kind of auto tuning.

BUT --- can't almost all of this tuning happen via a combination of eBPF and userspace supervision? AI inference isn't exactly known to be a lightweight or low-latency operation. In every scenario I can imagine, punting a kernel tuning decision to userspace would not impose meaningful cost overhead relative to any ML stuff userspace might want to do.

So, while I'm generally pretty gung-ho about applying AI to systems engineering problems, this particular patch seems like the wrong way to go about it.

Shouldn't this be in userspace?

Posted Feb 8, 2026 16:19 UTC (Sun) by RazeLighter777 (subscriber, #130021) [Link]

Agreed. There is nothing preventing anyone from making an program that reads from existing kernel hooks in eBPF, feeds it to and feeds it to ML model that controls eBPF program(s) for IO and CPU scheduling.

So this whole thing seems redundant and doable with current kernel APIs.

Shouldn't this be in userspace?

Posted Feb 13, 2026 2:39 UTC (Fri) by cypherpunks2 (guest, #152408) [Link] (1 responses)

> AI inference isn't exactly known to be a lightweight or low-latency operation.

That really depends. The Opus encoder, for example, has a speech/music detection gated recurrent unit (GRU) with less than 5k weights and can detect, in real time with hysteresis and while using less than 0.02% of the CPU, whether or not any given 20 ms audio frame has transitioned from speech to music (and vice versa): https://jmvalin.ca/opus/opus-1.3/. Any time you call someone over WebRTC (and pretty much every common VoIP protocol), you'll be doing inference with this model 50 times per second without even realizing it.

And a GRU isn't just a trivial feedforward neural network; It has memory that allows it to keep some information for a long time while discarding other information more quickly. When your problem space is very small, you can make a model that is exceptionally lightweight for both training and inference.

Not all "AI" models are massive, bloated large language models with billions of weights.

Shouldn't this be in userspace?

Posted Feb 13, 2026 2:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> Not all "AI" models are massive, bloated large language models with billions of weights.

Yeah, but if they are, then we can fuel an exorbitant amount of capital expenditure and generally just make lots of motion in the stock market. What else are these poor, bored VCs with billions burning holes in their pockets to do with it? Feed the hungry? End malaria?