On Fri, Jun 04, 2021 at 04:02:01AM +0200, Alessandro Pistocchi wrote: > > [...] > > My reasoning for not sending them is that the changes I made could create > security > issues for ordinary users, and I think that it would be a nightmare to > maintain only > to be able to play smoother games on a single platform, which in the grand > scheme > of things is quite small.
If you post a patch you should outline your security concerns in the mail. > To give you an idea, I am giving exclusive access to 3 out of 4 cpu cores > to a game Scheduler affinity control is useful in some cases. We don't have it, but it would be useful, even if only for testing purposes. If we were to add new scheduler system calls, e.g. sched_setaffinity(2), they would need to be compatible with Linux at minimum. > and I give the game quite a few pages of contiguous memory for the > framebuffer. I don't know anything about this. > I give all that back to openbsd when the game ends. OpenBSD cannot interrupt > the game on those 3 cores, it can only kill the game if needed. That's not > stuff that > should go into the official kernel, right? It depends. There are legitimate reasons for the superuser to isolate a process to a CPU or set of CPUs and exclude other processes from said CPUs. There are even legitimate reasons to disable scheduler preemption on a set of cores to allow for full "realtime" behavior, i.e. only voluntary preemption. This is a much more niche case, though. The problem with different scheduling strategies/disciplines is that you shrink the community of possible testers. A niche scheduling strategy necessarily gets less testing and accumulates bugs unless it has an evangelist maintaining it. A "sensible default" scheduling strategy is preferred because everyone uses it and the code is better field-tested. Fewer people can help you if you encounter a bug that only shows up when you give a single process (or group of processes) reign over a set of cores. You will necessarily encounter load balancing issues nobody has ever seen before. > [...] > > Is that acceptable? Or alternatively, what is the "right" way of doing > something like that? You should post your patches and provide an explanation of the benefits of such a feature. A minimal patch to plant your foot in the kernel is better than a huge patch that nobody wants to review. Complete manpages are a good way to show people you are serious.
