scx: Add maintainer and maintainer url to struct_ops

[hodgesds]

If the loaded BPF scheduler encounters an error finding the appropriate support will be challenging. Add fields to the struct_ops for sched_ext to include a scheduler maintainer and an optional support url.

[hodgesds]

@htejun this can probably wait until after the merge, just a thought I had to help improve support. Let me know what you think.

[arighi]

I think it's a great idea to have a designated place to report the official maintainer(s) for each scheduler. However, I'm concerned that this might encourage people to contact individuals directly, instead of opening issues on the github page.

For the sched_ext kernel patch itself, reaching out to the maintainers directly makes sense, because it's the "regular upstream kernel" workflow. But for the schedulers, if we want to continue using github, perhaps we should also include a message encouraging people to open an issue here in case of errors. WDYT?

[sirlucjan]

I think it would make sense to do something similar but also in scx-scheds. For example, at this point:

lucjan at cachyos ~ 12:29:47    
❯ sudo dmesg | grep -iF scheduler
[ 0.200859] BORE (Burst-Oriented Response Enhancer) CPU Scheduler modification 5.2.0 by Masahito Suzuki
[0.200917] rcu: RCU's calculated scheduling delay value is 100 jiffies.
[3.601058] io scheduler mq-deadline registered.
[3.601060] io scheduler kyber registered
[3.601073] io scheduler bfq registered
[3.601074] BFQ I/O-scheduler: BFQ-CachyOS v6.10 (with cgroups support)

Information about sched-ext in such a place would also be useful. As @arighi pointed out, it would be good to encourage users to report bugs on github, as direct contact with the maintainer of a given scheduler would deprive most users of insight into the current situation and the ability to see if the bug they are facing is also happening to other users

[hodgesds]

However, I'm concerned that this might encourage people to contact individuals directly, instead of opening issues on the github page.

Yeah, I think that is a valid concern. I think that's why I didn't want to do a check/validation on maintainer existing when the scheduler is loaded. I guess a maintainer URL is flexible enough you could do the assignment with something like:

https://github.com/sched-ext/scx/issues/new?assignees=<some_person>

But for the schedulers, if we want to continue using github, perhaps we should also include a message encouraging people to open an issue here in case of errors. WDYT?

I think that makes sense, I can make that message a little more clear on this URL should be used for support.

I think one of the concerns was that anyone can create whatever scheduler they want and the kernel has no way knowing where support should be directed, whether that is an individual or a Github repo. Maybe the best solution is having at least one different contact field required?

[hodgesds]

I've also though that maybe this should be a first class thing for struct_ops instead, but that would require more coordination with BPF folks.

[Byte-Lab]

Hmm, so, this seems like something that schedulers should be able to report from user space, or they can use the scx_bpf_dump_bstr() kfunc from the ops.dump(), ops.dump_cpu(), or ops.dump_task() callbacks to dump the line to the console.

[htejun]

I think it'd be useful to have some way to trace where the scheduler came from but I'm not sure including maintainer string is the right way. I wonder whether it'd be more useful / generic to be able to point back to the binary which loaded the scheduler. Then, the user or admin would be able to trace back using the usual mechanisms (e.g. querying package manager, checking versions and sha1 and so on). Also, this feels more like a generic BPF thing.