| View previous topic :: View next topic |
| Author |
Message |
von_kossa
n00b
Joined: 23 Feb 2007
Posts: 46
|
 Posted: Wed Jan 08, 2025 10:26 pm Post subject: CONFIG_SCHED_AUTOGROUP question |
 |
|
Hi!
Hopefully an easy one, going through my settings in my 6.8.12kernel i found that CONFIG_SCHED_AUTOGROUP was disabled, and frankly it looks like something you would like to have enabled.
Googling around a bit i found that many people mentioned that CONFIG_SCHED_ALT and CONFIG_SCHED_BMQ disabled CONFIG_SCHED_AUTOGROUP but i can´t even find ALT or BMQ, they seem to be missing.
So:
1. What happened with CONFIG_SCHED_ALT and CONFIG_SCHED_BMQ, were they removed?
2. Should CONFIG_SCHED_AUTOGROUP be enabled in 2025 or is there som caveat?
Thanks in advance |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5298
Location: Bavaria
|
|
| Back to top |
|
|
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 207
|
| Posted: Thu Jan 09, 2025 2:11 pm Post subject: Re: CONFIG_SCHED_AUTOGROUP question |
|
|
| von_kossa wrote: | Hi!
2. Should CONFIG_SCHED_AUTOGROUP be enabled in 2025 or is there som caveat?
|
There are caveats to consider.
Nice values and scheduling attributes such as SCHED_IDLE may break when you use autogroups. Here is an old thread where I complained and found a solution to the problem: https://forums.gentoo.org/viewtopic-t-1060648.html
I am still using autogroups and that Cgroup workaround to this day but if you use Systemd there may be more elegant solutions available. |
|
| Back to top |
|
|
von_kossa
n00b
Joined: 23 Feb 2007
Posts: 46
|
| Posted: Sat Jan 11, 2025 10:05 pm Post subject: |
|
|
Thank you all, i have enabled the setting.
Great link with recommended settings.  |
|
| Back to top |
|
|
Gentoopc
Guru
Joined: 25 Dec 2017
Posts: 372
|
| Posted: Sun Jan 12, 2025 8:31 am Post subject: Re: CONFIG_SCHED_AUTOGROUP question |
|
|
Guys, all this does not work well. Scheduling is very complex, it is carried out both in the Linux kernel and in the CPU. In this case, another scheduler is needed, which will regulate the work of all schedulers. Maybe it would even be possible to make an intelligent scheduler based on a cut-down GPT, the processor has an NPU, but that's not all. But if we had 6000 CUDA cores like on the GPU, or even 20000, then there would be no need for schedulers. There would be no queues. A real-time kernel on the GPU would make life on the Gentoo distribution very interesting. These are unlimited possibilities, which, unfortunately, we will not be given. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22981
|
| Posted: Sun Jan 12, 2025 3:37 pm Post subject: |
|
|
| Yes, if we had unlimited resources so that nothing needed to wait, we would have no need to schedule anything. We do not have unlimited resources, and on most systems, processes need to wait their turn. The kernel's scheduler tries its best to do the most good with the resources available. Part of that is allocating as little time to the scheduler itself as possible, since time spent making a decision about what to run is time not spent actually running anything the user wants done. Are you really suggesting that we use a Generative Predictive Text model, which is infamous not just for its mistakes but for its extremely high resource requirements, to make decisions that need to be made accurately, cheaply, and quickly? |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1381
Location: Richmond Hill, Canada
|
| Posted: Sun Jan 12, 2025 4:04 pm Post subject: |
|
|
Conceptually I agree with Gentoopc. It would be nice that linux kernel can utilise every available resource on the box (NPU/GPU etc...). Kernel offload task on to NPU/GPU would be very nice.
However I think current technology are limited in sense that the time passing data between CPU and NPU/GPU would be too long. so doing offload don't benefit for performance wise.
I also agree with Hu's point about using Generative Prediction text model for calculate process scheduler is way too expensive (resources and times wise) so it is not worthy. |
|
| Back to top |
|
|
|
Kernel & Hardware
