Conversation
I guess a lru_ext proposal is only a question of time now? Maybe even oom_ext although the userspace oomd's might be sufficient.
2
2
5
@vbabka On one hand all the _ext things make people happy because getting the extension interface is the last thing they need before never having to talk to the community again.
On the other hand, you can always reject a report because "oh you're using your own _ext code". And it won't be entirely wrong.
The extensions can of course spark interest in experimenting in some difficult areas, like the scheduler. The best outcome is to incorporate the good things back, if that happens. If. IF.
On the other hand, you can always reject a report because "oh you're using your own _ext code". And it won't be entirely wrong.
The extensions can of course spark interest in experimenting in some difficult areas, like the scheduler. The best outcome is to incorporate the good things back, if that happens. If. IF.
1
0
1
Petr Tesarik
ptesarik@fosstodon.org@kdave @vbabka I don't think that's the point. The “good” things are going to be good for just one purpose. Should mainline really care about a scheduler that was fine-tuned for one particular game?
But that's the deal. A single-purpose scheduler will always beet a generic one for a given application, because it has a lot of prior knowledge about the workload. That's also why its development cycle should be tied to the application, not to the Linux kernel.
0
0
2