** Summary changed:

- apply sched-ext patch set to linux-unstable
+ provide a sched-ext enabled kernel for the 24.10 release

** Also affects: linux (Ubuntu Oracular)
   Importance: Undecided
       Status: New

** No longer affects: linux (Ubuntu Noble)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045503

Title:
  provide a sched-ext enabled kernel for the 24.10 release

Status in linux package in Ubuntu:
  New
Status in linux source package in Oracular:
  New

Bug description:
  [Impact]

  sched-ext is a new scheduling class introduced in the Linux kernel
  that provides a mechanism to implement scheduling policies as eBPF
  programs (https://lwn.net/Articles/922405/). Such programs can also be
  connected to user-space counterparts to defer scheduling decisions to
  regular user-space processes.

  The idea of "pluggable" schedulers is not new, it was initially
  proposed in 2004 (https://lwn.net/Articles/109458/), but at that time
  it was strongly rejected, to prioritize the creation of a single
  generic scheduler (one to rule them all), that ended up being the
  “completely fair scheduler” (CFS).

  However, with BPF and the sched-ext scheduling class, we now have the
  possibility to easily and quickly implement and test scheduling
  policies, making the “pluggable” approach an effective tool for easy
  experimentation.

  The ability to implement custom scheduling policies via BPF greatly
  lowers the difficulty of testing new scheduling ideas (much easier
  than changing CFS or replacing it with a different scheduler). With
  this feature researchers or developers can test their own scheduler in
  a safe way, without even needing to reboot the system.

  Shipping this feature in the Ubuntu kernel can provide a significant
  benefit to researchers and companies that want to experiment (or ship)
  their own scheduling policy, implemented as an eBPF/user-space
  program.

  Targeting linux-unstable only for now is probably a good compromise to
  allow users to start some experiments, collect feedbacks, help the
  upstream community to find and fix bugs and at the same time avoid to
  introduce too much maintenance burden on us.

  [Test case]

  Basic test cases for this feature are provided by the sched-ext patch
  set. Tests and custom scheduler implementations are available in
  tools/sched_ext or in https://github.com/sched-ext/scx.

  [Fix]

  Apply this patch set as SAUCE to linux-unstable:
  https://lore.kernel.org/bpf/zvpjtc5znenny...@slm.duckdns.org/T/

  On top of the patch set we want to apply also the following patches
  (still as SAUCE):

   - UBUNTU: SAUCE: sched_ext: use proper atomic operator for scx.ops_state
     (extra fix to properly build sched-ext on armhf)

   - UBUNTU: SAUCE: sched-ext: taint kernel when a custom scheduler is loaded
     (set TAINT_OOT_MODULE in /proc/sys/kernel/tainted to easily determine when 
a custom scheduler has been used, that can be useful for bug reports: we can 
easily detect when a custom scheduler has been used and treat the bug report 
accordingly)

   - UBUNTU: [Config] enable sched_ext in annotations
     (enable sched-ext in the config across all the supported architectures)

  Soon there will be a branch against any kernel that we need here (we will 
only need 6.7 for now):
  https://github.com/sched-ext/sched_ext

  [Regression potential]

  This feature is not going to be merged upstream in the near future,
  some upstream maintainers are worried that giving the possibility to
  inject in the kernel a custom scheduler can introduce performance
  regressions that are hard to track down.

  For this reason we should apply this feature only to linux-unstable
  for now, making sure that the patch is unapplied or reverted when
  linux-unstable becomes linux.

  In the meantime we can also figure out a reasonable way to determine
  when a custom scheduler is used (i.e., taint the kernel?) to easily
  determine when any potential performance regression may have been
  introduced by a custom sched-ext scheduler.

  From a maintenance perspective, having this patch set applied may also
  be problematic (potential conflicts) when we apply new stable updates.
  However, the upstream maintainers of sched-ext have expressed interest
  to help us maintaining the patch set against the target kernel(s) that
  we need. And targeting linux-unstable only can definitely mitigate the
  maintenance problem a lot (since we won't have the urgency to apply
  critical security fixes to linux-unstable).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045503/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to