Bugzilla – Bug 1125004
Change default kconfig: CONFIG_PREEMPT_VOLUNTARY
Last modified: 2024-06-25 13:51:30 UTC
As discussed on opensuse-kernel ML, there is a request to switch the kernel default config for preemption to CONFIG_PREEMPT_VOLUNTARY from the current CONFIG_PREEMPT on Tumbleweed: https://lists.opensuse.org/opensuse-kernel/2019-02/msg00005.html Originally, this theme was raised from another bug 1112824, where it indicated that CONFIG_PREEMPT_VOLUNTARY works around the GNOME performance problem. Although switching the preemption behavior shouldn't be taken as the fix for the problem above, we can consider it as a good chance to switch. As found in the discussion thread above, other major distros (Fedora and Ubuntu) use CONFIG_PREEMPT_VOLUNTARY as default. So this should be good enough for the interactivity we wanted to achieve with CONFIG_PREEMPT, while it must be better in terms of the throughput. Moreover, the current TW kernel config has very inconsistency; only a few (x86_64/default, armv7hl/default and lpae, and i386/pae) take CONFIG_PREEMPT=y while others take CONFIG_PREEMPT_NONE=y. This inconsistency likely came from the fact that SLE and Leap kernels take CONFIG_PREEMPT_NONE=y for all flavors. So, we should change all to CONFIG_PREEMPT_VOLUNTARY=y for all flavors on TW from consistency POV, too. Also, it'd be a good timing to switch the Leap 15.1 config as well, so that we can align the behavior with TW kernel.
I'm not opposed to the idea in principle. IIRC CONFIG_PREEMPT_VOLUNTARY was not available at the time we changed it last time (when we dropped -desktop flavor and switched -default to preemptive in openSUSE kernels) so it makes sense to reevaluate. What makes a bit reluctant are two things: 1. Mike - whose judgment on the topic I value most - seems to be the least eager about the change and the least convinced about the expected benefits. 2. We are talking about config option with potential to touch any workload in not easily predictable way. I'm wouldn't be happy if the motivation was to work around a specific bug which may be gone soon. So I would suggest, for the purpose of this discussion, to ignore bsc#1112824 and focus only on the global and long term effects. A note on openSUSE-15.1: it certainly makes sense to align it with Tumbleweed (whatever we pick for it). But if it is going to differ from SLE15-SP1, every member of SUSE kernel teams should be aware of it so that they don't skip some mainline backports just because they only affect the preemptive case (which we sometimes did in the past).
I also curious how it affects power consumption, if at all.
(In reply to Michal Kubeček from comment #1 > 1. Mike - whose judgment on the topic I value most - seems to be the least > eager about the change and the least convinced about the expected benefits. > Are we talking about the same Mike who said the following on the list thread “I personally prefer (and use) VOLUNTARY due to its better throughput, and have no issue with it being selected in general. ” and “I prefer PREEMPT_VOLUNTARY, so would recommend that.” That does not seem to be an uneager view on this change. > 2. We are talking about config option with potential to touch any workload in > not easily predictable way. I'm wouldn't be happy if the motivation was to > work around a specific bug which may be gone soon. So I would suggest, for > the purpose of this discussion, to ignore bsc#1112824 and focus only on the > global and long term effects. Fair, but I would still advocate for this change on the grounds of its common adoption across desktop centric distributions as it provides a better balance than PREEMPT being on > A note on openSUSE-15.1: it certainly makes sense to align it with Tumbleweed > (whatever we pick for it). But if it is going to differ from SLE15-SP1, every > member of SUSE kernel teams should be aware of it so that they don't skip > some > mainline backports just because they only affect the preemptive case (which > we > sometimes did in the past).
(In reply to Richard Brown from comment #3) > Are we talking about the same Mike who said the following on the list thread > > “I personally prefer (and use) VOLUNTARY due to its better throughput, > and have no issue with it being selected in general. ” > > and “I prefer > PREEMPT_VOLUNTARY, so would recommend that.” > > That does not seem to be an uneager view on this change. Yes, that Mike. Except for two important points: 1. That mail you quoted, was written yesterday, i.e. a week after comment 1 2. It was in the context of a reply to "For a desktop user who might like to use their computer interactively and use it to play music or strea a video while they compile the kernel, which would be the recommended kernel model?" (The first half was from an earlier e-mail but also in the context of much longer text which, as a whole, sounded far less unambiguous than this short excerpt.) So let's ask directly: Mike, to you think CONFIG_PREEMPT_VOLUNTARY (which was IIRC not available when this was discussed last time) would be better default for general openSUSE user experience? (Also adding Matt and Frederic woul could also provide valuable insight.) > Fair, but I would still advocate for this change on the grounds of its > common adoption across desktop centric distributions as it provides a better > balance than PREEMPT being on Yes, those are certainly valid points. I didn't mean to pretend the Gnome bug was the only argument for the change. I just suggested to completely ignore that particular argument and focus on the rest.
Oops... forgot to set the needinfo. The question is: Mike, to you think CONFIG_PREEMPT_VOLUNTARY (which was IIRC not available when this was discussed last time) would be better default for general openSUSE user experience?
(In reply to Michal Kubeček from comment #5) > Oops... forgot to set the needinfo. > > The question is: Mike, to you think CONFIG_PREEMPT_VOLUNTARY (which was IIRC > not available when this was discussed last time) would be better default for > general openSUSE user experience? Yes, IMO it is the best option. PREEMPT never was the interactivity silver bullet that some tend to think of it as being, it helping not at all with the all time #1 source of interactivity woes, IO latency.
Thank you. I'll apply the change in master branch later today (for all architectures). The stable branch will inherit it with 5.0 final unless Jiří Slabý updates the configs earlier. Adding Petr Tesařík (openSUSE-15.1 branch maintainer).
FYI: configs in master branch have been updated so that PREEMPT_VOLUNTARY is now used everywhere except for s390x/zfcpdump (left with PREEMPT_NONE) and 32-bit ARM architectures which are currently disabled as the configs haven't been updated for 5.0-rc* yet. If someone wants to give it a try, 5.0-rc7-2 packages published in http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ (x86_64, i586) and .../PPC/ (ppc64le, ppc64) already have this change. The aarch64 packages (to appear in .../ARM/) are still building.
(In reply to Michal Kubeček from comment #7) > architectures). The stable branch will inherit it with 5.0 final unless Jiří > Slabý updates the configs earlier. Given -rc8 was released (and not -final), let's take the configs earlier, so that people do not connect eventual errors to the 4.19 -> 5.0 switch, but to this config change.
Let's document the accompanying changes for the record: -CONFIG_PREEMPT_RCU=y +CONFIG_TREE_RCU=y -CONFIG_CEC_GPIO=m -CONFIG_UNINLINE_SPIN_UNLOCK=y +CONFIG_INLINE_SPIN_UNLOCK_IRQ=y +CONFIG_INLINE_READ_UNLOCK=y +CONFIG_INLINE_READ_UNLOCK_IRQ=y +CONFIG_INLINE_WRITE_UNLOCK=y +CONFIG_INLINE_WRITE_UNLOCK_IRQ=y CEC_GPIO depends on PREEMPT for to me unknown reason. But the author of the driver says: "the main use-case of this driver is to function as a debugging tool." So if anyone wants it back, upstream is awaiting your patches :).
Normally, I would suggest to keep such change only in Tumbleweed for few weeks before apllying to Leap. But as openSUSE-15.1 is in beta phase, we might rather prefer to switch as early as possible to have more time (and free hands - with kABI not frozen yet) to handle the fallout if there is any. Petr, what do you think?
I have already discussed the change with Takashi, and it's better to switch now also for Leap. Will do.
This is an autogenerated message for OBS integration: This bug (1125004) was mentioned in https://build.opensuse.org/request/show/680183 15.1 / kernel-source
OK, now we all set. Let's close. Thanks!