Date: Fri, 17 Nov 2023 12:12:05 +0100 From: Olivier Certner <olivier.freebsd@free.fr> To: freebsd-arch@freebsd.org Subject: Suppressing the _KPOSIX_PRIORITY_SCHEDULING kernel config option Message-ID: <5428029.vKySYWdmsc@ravel>
next in thread | raw e-mail | index | archive | help
Hello, As part of my current work on rationalizing/fixing scheduling priorities, both from the point of view of users and internally, I've stumbled on this kernel config option. It currently controls whether the system calls related to process scheduling are compiled in instead of providing stubs. Here's the system calls list: - sched_setscheduler()/sched_getscheduler() - sched_setparam()/sched_getparam() - sched_yield() - sched_get_priority_max()/sched_get_priority_min()/sched_rr_get_interval() There are some problems with this build option: 1. These system functions are defined by the current POSIX standard as being part of the PS (Process Scheduling) and TPS (Thread Execution Scheduling) options, which also define a number of other ones (e.g., pthread_getschedparam()/pthread_setschedparam(), pthread_setschedprio() and a bunch of similar pthread_attr_*() functions) that by contrast we *unconditionally* provide (i.e., irrespective of _KPOSIX_PRIORITY_SCHEDULING). This is inconsistent. 2. The priority values handling it needs to implement is common to other parts, such as the PTHREAD_PRIO_PROTECT mutexes (POSIX options TPP and RPP, Non-Robust/Robust Mutex Priority Protection), which again we unconditionally provide. 3. The kernel currently doesn't compile without it. Additionally: 1. The code under _KPOSIX_PRIORITY_SCHEDULING is just a translation layer to the RT priorities facility which is the real implementation and, as you guessed it, again cannot be compiled out. 2. _KPOSIX_PRIORITY_SCHEDULING is present in MINIMAL (probably because of 3. above). 3. Quick-patching 3. above, I observe that the kernel size increase caused by this option is a whopping 4456 bytes (with debug options enabled). For all these reasons, I'm planning to just remove _KPOSIX_PRIORITY_SCHEDULING and have the code it controls always compiled in. An alternative would be the painful work of determining what would make sense to fall under this option and effectively separating the code properly, but I don't think it's worth it, and as can be seen from above the status quo is not satisfying either. Any objections? Or other thoughts? Thanks and regards. -- Olivier Certner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5428029.vKySYWdmsc>