From nobody Fri Nov 17 11:12:05 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SWvPQ2mKsz50rLL for ; Fri, 17 Nov 2023 11:12:10 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SWvPP32sQz3HJ6 for ; Fri, 17 Nov 2023 11:12:09 +0000 (UTC) (envelope-from olivier.freebsd@free.fr) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=free.fr header.s=smtp-20201208 header.b=PG+2ETZ1; spf=pass (mx1.freebsd.org: domain of olivier.freebsd@free.fr designates 212.27.42.2 as permitted sender) smtp.mailfrom=olivier.freebsd@free.fr; dmarc=pass (policy=none) header.from=free.fr Received: from ravel.localnet (unknown [90.118.140.172]) (Authenticated sender: olivier.freebsd@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 4D0542003C1 for ; Fri, 17 Nov 2023 12:12:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1700219526; bh=cnD0xew82JyohBJCASQvkaviVbc6lDVBQgzi/f3EmW8=; h=From:To:Subject:Date:From; b=PG+2ETZ1T2RV1jGrpNuDEvNBboZAA7ROa0t4WPAD61RNTOW7HBvbE/8/YxgW2ne62 RgxLMCvAf0/z13mVDQfSpYAepUIX02Oq4D9DgmCS0JoRGaIgHH2OqRUMdJGevk4sVY JDgM14frOV0UT2Ddl9W2g/1Znq+kOw4ALJwdZtyMPRCMoXM/OEDO4rxYZF9Q3V8YNV 9i8B5SSksXntmH+zH9O9HaN/vyDGmCuL1vmOixd/UTbDRLBDSaJsmRWReg9Q9JSSnn rTZoxnl+F22Zg9m2v2B7XrH2IfjlpM0DWZoiHamFb5b4EUQl9sJQKwDBbEzVHScbXW x8k4kn8h9iuOQ== From: Olivier Certner To: freebsd-arch@freebsd.org Subject: Suppressing the _KPOSIX_PRIORITY_SCHEDULING kernel config option Date: Fri, 17 Nov 2023 12:12:05 +0100 Message-ID: <5428029.vKySYWdmsc@ravel> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-1.18 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.82)[0.818]; DMARC_POLICY_ALLOW(-0.50)[free.fr,none]; CTE_CASE(0.50)[]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:212.27.42.2]; R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[212.27.42.2:from]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[free.fr:dkim]; FREEMAIL_ENVFROM(0.00)[free.fr]; DKIM_TRACE(0.00)[free.fr:+]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[free.fr]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:12322, ipnet:212.27.32.0/19, country:FR]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4SWvPP32sQz3HJ6 X-Spamd-Bar: - 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