Development project for hosting sched-ext (Kernel:sched-ext?)
Hi, sched-ext is a BPF extensible scheduler class that aims to make experimentation and exploration easier (among other goals). It currently live as out-of-tree Linux Kernel patchset[1], but has been either already in-use or considered by Valve, Meta/Oculus, and ChromOS[1]. Fredrik (Lönnegren) is currently working on it in home:flonnegren:sched-ext. While that works, it would certainly be nice to have its own project to host both the kernel and associated userspace[2] components. Given it is kernel-related, I naturally gravitates towards having a "Kernel:sched-ext" subproject and from there have Kernel:sched-ext:HEAD (akin to Kernel:HEAD) and Kernel:sched-ext:stable (akin to Kernel:stable). @Kernel project maintainers do you think that can be considered? Or perhaps something like devel:sched-ext if not under the Kernel project. It should be noted that there are opposition for merging sched-ext into the Linux Kernel[3], so it is unclear whether and when this project can eventually be deprecated. But in the mean time giving other a easier way to give sched-ext a try doesn't seem like a bad idea. Cheers, Shung-Hsi Yu 1: https://lore.kernel.org/all/20240501151312.635565-1-tj@kernel.org/ 2: https://github.com/sched-ext/scx 3: https://lwn.net/Articles/972710/
Hello, On Tue, May 28, 2024 at 03:34:35PM +0800, Shung-Hsi Yu wrote:
Hi,
sched-ext is a BPF extensible scheduler class that aims to make experimentation and exploration easier (among other goals). It currently live as out-of-tree Linux Kernel patchset[1], but has been either already in-use or considered by Valve, Meta/Oculus, and ChromOS[1].
Fredrik (Lönnegren) is currently working on it in home:flonnegren:sched-ext. While that works, it would certainly be nice to have its own project to host both the kernel and associated userspace[2] components. Given it is kernel-related, I naturally gravitates towards having a "Kernel:sched-ext" subproject and from there have Kernel:sched-ext:HEAD (akin to Kernel:HEAD) and Kernel:sched-ext:stable (akin to Kernel:stable). @Kernel project maintainers do you think that can be considered?
I do not think making sched-ext work available in a project under Kernel makes it any easier for people to use it than installing from a home project. The Kernel project makes use of the kbuild automation to upload the content of the kernel-source git tree. Since you do not maintain the sched-ext in kernel-source there is no reason to share that project. Thanks Michal
On Tue, May 28, 2024 at 10:33:10AM GMT, Michal Suchánek wrote:
On Tue, May 28, 2024 at 03:34:35PM +0800, Shung-Hsi Yu wrote:
sched-ext is a BPF extensible scheduler class that aims to make experimentation and exploration easier (among other goals). It currently live as out-of-tree Linux Kernel patchset[1], but has been either already in-use or considered by Valve, Meta/Oculus, and ChromOS[1].
Fredrik (Lönnegren) is currently working on it in home:flonnegren:sched-ext. While that works, it would certainly be nice to have its own project to host both the kernel and associated userspace[2] components. Given it is kernel-related, I naturally gravitates towards having a "Kernel:sched-ext" subproject and from there have Kernel:sched-ext:HEAD (akin to Kernel:HEAD) and Kernel:sched-ext:stable (akin to Kernel:stable). @Kernel project maintainers do you think that can be considered?
I do not think making sched-ext work available in a project under Kernel makes it any easier for people to use it than installing from a home project.
The Kernel project makes use of the kbuild automation to upload the content of the kernel-source git tree. Since you do not maintain the sched-ext in kernel-source there is no reason to share that project.
Thanks for the explanation, fair points. Kernel project should be for content of kernel-source and sched-ext doesn't fit in there. Regarding development project vs home project, let me pivot a bit. Yes, there's no different when it comes to installion, but a development project offers a sense of credibility that home project cannot, and hint that it is a group effort that will be continuously maintained, rather than a one-shot attempt (only time will tell though (: ). Again, it's a nice to have; not having a development project certainly does not prevent us from working on sched-ext. Shung-Hsi
On Tue, 2024-05-28 at 20:03 +0800, Shung-Hsi Yu via openSUSE Factory wrote:
On Tue, May 28, 2024 at 10:33:10AM GMT, Michal Suchánek wrote:
On Tue, May 28, 2024 at 03:34:35PM +0800, Shung-Hsi Yu wrote:
sched-ext is a BPF extensible scheduler class that aims to make experimentation and exploration easier (among other goals). It currently live as out-of-tree Linux Kernel patchset[1], but has been either already in-use or considered by Valve, Meta/Oculus, and ChromOS[1].
Fredrik (Lönnegren) is currently working on it in home:flonnegren:sched-ext. While that works, it would certainly be nice to have its own project to host both the kernel and associated userspace[2] components. Given it is kernel-related, I naturally gravitates towards having a "Kernel:sched-ext" subproject and from there have Kernel:sched-ext:HEAD (akin to Kernel:HEAD) and Kernel:sched-ext:stable (akin to Kernel:stable). @Kernel project maintainers do you think that can be considered?
I do not think making sched-ext work available in a project under Kernel makes it any easier for people to use it than installing from a home project.
The Kernel project makes use of the kbuild automation to upload the content of the kernel-source git tree. Since you do not maintain the sched-ext in kernel-source there is no reason to share that project.
Thanks for the explanation, fair points. Kernel project should be for content of kernel-source and sched-ext doesn't fit in there.
Just FTR, it seems that sched-ext is hitting upstream sooner than expected. :-) https://lore.kernel.org/lkml/CAHk-=wg8APE61e5Ddq5mwH55Eh0ZLDV4Tr+c6_gFS7g2Ax... Regards, -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
participants (3)
-
Dario Faggioli -
Michal Suchánek -
Shung-Hsi Yu