#228 Enable full preemption
Opened 6 months ago by chrismurphy. Modified a month ago

Now that a single kernel can use preemption none/voluntary/full, we should evaluate the pros and cons of preempt=voluntary (the current default) versus preempt=full.

relevant message in devel@ thread:Dynamic preemption support in Linux 5.12 kernel.

This would be configured with a boot parameter, so it could be an edition/spin specific option. But we need to figure out how to add it in a configurable way. Maybe it can be done with a dracut drop-in config file?

There's other work happening with resource control, so part of the investigation should consider any conflicts, or other downsides.

@benzea


Metadata Update from @chrismurphy:
- Issue tagged with: pending-action

6 months ago

I would prefer that if we decide to do this, we should make this a default for all variants unless someone specifically wants to opt-out. Pretty much everything I have read on this seems to indicate the downsides are relatively minimal across the board.

I believe that this issue can be considered entirely independent from other resource control problems.

Personally, I am wondering a bit how exactly preemption helps here. Is the problem here that spinning up another core is costly, so we should preempt kernel tasks in order to run userspace earlier? i.e.:

CPU0: [kernel input] -> [other kernel task] -> userspace input -> ...
vs. with preemption:
CPU0: [kernel input] -> userspace input -> [other kernel task] -> ...

I've asked Tejun Heo about this, and he's confirmed there shouldn't be any impact on resource control specifically (and if there is, it's a bug we should fix).

I expect for the desktop case, it is a win across the board. There are certain server workloads where it can be a problem. I am not particularly comfortable switching defaults in the middle of a stable release though, particularly when we have so much testing with preempt voluntary (RHEL uses voluntary as well, and does a lot more performance testing than we do). Hopefully we can get a patch which lets us keep the default and still use dynamic so that F33/F34 users will benefit.

Wouldn't it make sense for these to be configurable through the tuning daemon (tuned)? That seems like what this is for...

BTW, this is how to change preempt on-the fly:

# cat /sys/kernel/debug/sched_preempt
(none) voluntary full

# echo full > /sys/kernel/debug/sched_preempt

# cat /sys/kernel/debug/sched_preempt
none voluntary (full) 

Would be nice to make preemptctl.

Sounds like Workstation should switch to preempt for F35.

I agree with Justin that there's no strong reason to make major changes like this in a stable release.

Wouldn't it make sense for these to be configurable through the tuning daemon (tuned)? That seems like what this is for...

We do not install tuned in Workstation.

We do not install tuned in Workstation.

why not? It's easy to do this.

Nobody has ever proposed it afaik.

/sys/kernel/debug/sched_preempt

debugfs is subject to kernel lockdown, which is in effect for UEFI Secure Boot systems, so currently it can't be checked or changed during runtime.

[  531.180062] Lockdown: cat: debugfs access is restricted; see man kernel_lockdown.7

Hmm, apparently there's now a GUI applet for tuned made by @xvitaly: https://github.com/EasyCoding/tuned-switcher

Hmm, apparently there's now a GUI applet for tuned made by @xvitaly: https://github.com/EasyCoding/tuned-switcher

System tray applet is fully functional:

  • full D-Bus support;
  • profile monitoring (will report if another application changes the profile);
  • easy profile switching;
  • shows currently selected profile;
  • supports automatic mode.

Screenshots:

Screenshot

GUI version is still in development.

Packaged and can be installed via sudo dnf install tuned-switcher.

The workstation UI for such things is in the control-center

The workstation UI for such things is in the control-center

power-profiles-daemon devs said that it will not work on desktop Ryzen PC's for example. And it doesn't work not only on desktop Ryzens. Maybe just at this moment and this temporary, so this is JFYI.

This ticket is tagged with pending-action and the F35 milestone. What needs to be done?

Nothing yet, as the patch that allows us to switch preempt mode from where we are doesn't seem to exist yet. I pinged Lutro on the fedora-devel thread to see if it is in progress. Once that patch goes in (and the resulting kernel is available as a rebase target for stable Fedora), is the time to start testing switching the workstation defaults. Users on stable Fedora will be able to manually make the switch, and then you can make a decision on setting a default for the next version. As it doesn't seem to be in 5.14, it will likely not be on the install kernel for F35

Metadata Update from @aday:
- Issue set to the milestone: Fedora 36 (was: Fedora 35)

a month ago

Login to comment on this ticket.

Metadata