[opensuse-kernel] Proposal - CONFIG_PREEMPT_VOLUNTARY for TW Kernel
Hi all, I was talking to Takashi lately about the saga that is bug 1112824 http://bugzilla.opensuse.org/show_bug.cgi?id=1112824 In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them However, as a heavy GNOME user, in my own testing, I have found the following results CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824 CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME I can understand the reluctance to change a kernel config option just because of a bug, and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace. That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option. Therefore after this testing I'm convinced that CONFIG_PREEMPT_VOLUNTARY is a better default for the Tumbleweed kernel-default than the current CONFIG_PREEMPT What do you all think? Regards, Richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
Hm, what distros use PREEMPT_VOLUNTARY? While PREEMPT_VOLUNTARY is my personal preference as a compromise between throughput and latency (PREEMPT injures throughput way too much for my taste), I have for years been under the impression that most if not all distros were shipping PREEMPT kernels.
I can understand the reluctance to change a kernel config option just because of a bug, and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace.
That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option.
Scanning through the BNC, I don't see any reason to consider changing the long used preemption model. It looks to me like something simply went broke recently (as things occasionally do), and that something needs to be hunted down and fixed up. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 07 Feb 2019 08:05:30 +0100, Mike Galbraith wrote:
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
Hm, what distros use PREEMPT_VOLUNTARY? While PREEMPT_VOLUNTARY is my personal preference as a compromise between throughput and latency (PREEMPT injures throughput way too much for my taste), I have for years been under the impression that most if not all distros were shipping PREEMPT kernels.
Actually, both Fedora and Ubuntu use PREEMPT_VOLUNTARY as default. (Ubuntu provides PREEMPT kernel variant, in addition.) Arch seems using PREEMPT, though.
I can understand the reluctance to change a kernel config option just because of a bug, and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace.
That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option.
Scanning through the BNC, I don't see any reason to consider changing the long used preemption model. It looks to me like something simply went broke recently (as things occasionally do), and that something needs to be hunted down and fixed up.
OTOH, originally CONFIG_PREEMPT was taken exactly for a better desktop usage, and now this showed failing. Moreover, other major distros use PREEMPT_VOLUNTARY. So, overall, this shouldn't be seen as a "fix", but it's a good timing for switching, IMO. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----Original Message----- From: Takashi Iwai <tiwai@suse.de> Sent: 07 February 2019 08:53 To: Mike Galbraith <mgalbraith@suse.de> Cc: Richard Brown <RBrownCCB@opensuse.org>; opensuse- kernel@opensuse.org Subject: Re: [opensuse-kernel] Proposal - CONFIG_PREEMPT_VOLUNTARY for TW Kernel
On Thu, 07 Feb 2019 08:05:30 +0100, Mike Galbraith wrote:
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was
provided,
and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
Hm, what distros use PREEMPT_VOLUNTARY? While PREEMPT_VOLUNTARY is my personal preference as a compromise between throughput and latency (PREEMPT injures throughput way too much for my taste), I have for years been under the impression that most if not all distros were shipping PREEMPT kernels.
Actually, both Fedora and Ubuntu use PREEMPT_VOLUNTARY as default. (Ubuntu provides PREEMPT kernel variant, in addition.)
Arch seems using PREEMPT, though.
I can understand the reluctance to change a kernel config option just because of a bug, and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace.
That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option.
Scanning through the BNC, I don't see any reason to consider changing the long used preemption model. It looks to me like something simply went broke recently (as things occasionally do), and that something needs to be hunted down and fixed up.
OTOH, originally CONFIG_PREEMPT was taken exactly for a better desktop usage, and now this showed failing. Moreover, other major distros use PREEMPT_VOLUNTARY. So, overall, this shouldn't be seen as a "fix", but it's a good timing for switching, IMO.
And move aarch64 out of PREEMPT_NONE! Thanks, Guillaume
thanks,
Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 2019-02-07 at 08:52 +0100, Takashi Iwai wrote:
On Thu, 07 Feb 2019 08:05:30 +0100, Mike Galbraith wrote:
Scanning through the BNC, I don't see any reason to consider changing the long used preemption model. It looks to me like something simply went broke recently (as things occasionally do), and that something needs to be hunted down and fixed up.
OTOH, originally CONFIG_PREEMPT was taken exactly for a better desktop usage, and now this showed failing. Moreover, other major distros use PREEMPT_VOLUNTARY. So, overall, this shouldn't be seen as a "fix", but it's a good timing for switching, IMO.
I personally prefer (and use) VOLUNTARY due to its better throughput, and have no issue with it being selected in general. It's only the "this change fixes something" aspect that causes me serious concern. Note: the change will impact realtime latencies, so there's some potential for regression reports, though unlikely. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 07.02.19 um 08:05 schrieb Mike Galbraith:
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
I'm suffering at least on one of my machines from the performance hit introduced around October still. And I'm currently running a PREEMPT_VOLUNTARY kernel for testing. Still I do not see a noticeable difference fwiw. Someone called it microhangs and I have plenty of them. Just writing these lines is distracting when the system cannot follow in realtime while I'm typing not speaking about all the animation latencies and hangs. So I cannot provide much feedback about if this change is worth it for some or in general for some reasons. But it is certainly not changing my experience under TW/Gnome for the better :-( Wolfgang -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 7 Feb 2019 at 09:04, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 07.02.19 um 08:05 schrieb Mike Galbraith:
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
I'm suffering at least on one of my machines from the performance hit introduced around October still. And I'm currently running a PREEMPT_VOLUNTARY kernel for testing. Still I do not see a noticeable difference fwiw. Someone called it microhangs and I have plenty of them. Just writing these lines is distracting when the system cannot follow in realtime while I'm typing not speaking about all the animation latencies and hangs. So I cannot provide much feedback about if this change is worth it for some or in general for some reasons. But it is certainly not changing my experience under TW/Gnome for the better :-(
Yes, like Takashi says in the bug, there is probably no silver bullet VOLUNTARY improves things for me, it's aligned with what two other major distros do, it's what folks like Mike are using themselves, therefore I'd like everyone here to use this opportunity to consider changing it as our default also. I accept this might not fix the issue that triggered the bug..That bug has become a mess full of generic "meh things aren't as slow as they used to" complaints. Rather than dismiss them I think it's a good opportunity to snipe out what few things we can identify, consider, and improve compared to the status quo. In the bug there are (strangely private) comments in the bug suggesting that we should drop the IBRS handling we currently have and adopt EIBRS+retpolines like upstream That sounds like another reasonable step forward I'd like to see us consider and hopefully adopt, but given I don't have the problem as severely as you do I'm not in a position to test out the theory or vouch for it's sanity, so I'm left leaving that as a line of investigation I hope will be pursued by wiser brains. - Rich -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On jeudi, 7 février 2019 09.57:20 h CET Richard Brown wrote:
On Thu, 7 Feb 2019 at 09:04, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 07.02.19 um 08:05 schrieb Mike Galbraith:
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
I'm suffering at least on one of my machines from the performance hit introduced around October still. And I'm currently running a PREEMPT_VOLUNTARY kernel for testing. Still I do not see a noticeable difference fwiw. Someone called it microhangs and I have plenty of them. Just writing these lines is distracting when the system cannot follow in realtime while I'm typing not speaking about all the animation latencies and hangs. So I cannot provide much feedback about if this change is worth it for some or in general for some reasons. But it is certainly not changing my experience under TW/Gnome for the better :-(
Yes, like Takashi says in the bug, there is probably no silver bullet
VOLUNTARY improves things for me, it's aligned with what two other major distros do, it's what folks like Mike are using themselves, therefore I'd like everyone here to use this opportunity to consider changing it as our default also. I accept this might not fix the issue that triggered the bug..That bug has become a mess full of generic "meh things aren't as slow as they used to" complaints. Rather than dismiss them I think it's a good opportunity to snipe out what few things we can identify, consider, and improve compared to the status quo.
In the bug there are (strangely private) comments in the but suggesting that we should drop the IBRS handling we currently have and adopt EIBRS+retpolines like upstream
That sounds like another reasonable step forward I'd like to see us consider and hopefully adopt, but given I don't have the problem as severely as you do I'm not in a position to test out the theory or vouch for it's sanity, so I'm left leaving that as a line of investigation I hope will be pursued by wiser brains.
- Rich
Hi all, I'm a bit surprized, I didn't detect any of the hickup describe here during the last few month. I'm an happy (and loyal) plasma5 user :-) (If I activate the troll mode, I would recommend the changing desktop, but I will not, no time for that). So isn't there a kind of "scientist" method to meseaure and track it down ? If there's a bugzilla opened for this would you mind to be sure it is open for community review, access. Starting to change openSUSE kernel means having that option activated and only one kernel-flavor, or will we have -desktop kernel like we add several years ago ? I'm feeling that having an excellent openSUSE kernel also for server deploiement, container and so on is also vital. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 08 Feb 2019 20:55:47 +0100, Bruno Friedmann wrote:
On jeudi, 7 février 2019 09.57:20 h CET Richard Brown wrote:
On Thu, 7 Feb 2019 at 09:04, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Am 07.02.19 um 08:05 schrieb Mike Galbraith:
On Wed, 2019-02-06 at 16:34 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
I'm suffering at least on one of my machines from the performance hit introduced around October still. And I'm currently running a PREEMPT_VOLUNTARY kernel for testing. Still I do not see a noticeable difference fwiw. Someone called it microhangs and I have plenty of them. Just writing these lines is distracting when the system cannot follow in realtime while I'm typing not speaking about all the animation latencies and hangs. So I cannot provide much feedback about if this change is worth it for some or in general for some reasons. But it is certainly not changing my experience under TW/Gnome for the better :-(
Yes, like Takashi says in the bug, there is probably no silver bullet
VOLUNTARY improves things for me, it's aligned with what two other major distros do, it's what folks like Mike are using themselves, therefore I'd like everyone here to use this opportunity to consider changing it as our default also. I accept this might not fix the issue that triggered the bug..That bug has become a mess full of generic "meh things aren't as slow as they used to" complaints. Rather than dismiss them I think it's a good opportunity to snipe out what few things we can identify, consider, and improve compared to the status quo.
In the bug there are (strangely private) comments in the but suggesting that we should drop the IBRS handling we currently have and adopt EIBRS+retpolines like upstream
That sounds like another reasonable step forward I'd like to see us consider and hopefully adopt, but given I don't have the problem as severely as you do I'm not in a position to test out the theory or vouch for it's sanity, so I'm left leaving that as a line of investigation I hope will be pursued by wiser brains.
- Rich
Hi all, I'm a bit surprized, I didn't detect any of the hickup describe here during the last few month. I'm an happy (and loyal) plasma5 user :-) (If I activate the troll mode, I would recommend the changing desktop, but I will not, no time for that).
So isn't there a kind of "scientist" method to meseaure and track it down ?
Unfortunately the interactivity is one of the difficult things to measure quantitatively. Especially the desktop interactivity is majorly influenced by other factors like the hardware components, the file systems, usage patterns, and whatever. There are some unattended benchmarks, but it doesn't guarantee what you wanted to see.
If there's a bugzilla opened for this would you mind to be sure it is open for community review, access.
As Richard's original post mentioned, it started from bug 1112824. Take a look at it and enjoy, if not done yet :)
Starting to change openSUSE kernel means having that option activated and only one kernel-flavor, or will we have -desktop kernel like we add several years ago ?
I'm feeling that having an excellent openSUSE kernel also for server deploiement, container and so on is also vital.
If that option really matters and inevitably needed for majority of users, we can revive a new flavor, yes. But I strongly doubt it. The effect of CONFIG_PREEMPT is mostly likely a placebo for normal desktop usages. Only the very hard RT (like the realtime audio with a bad hardware combination) may see the clear difference. Unless we get a significant demand, we'd like to avoid creating another flavor for keeping the maintainability. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
In general, I do not run an openSUSE kernel. That is partly due to testing the kernel head, and because I do testing and updating of wireless drivers. My kernels are all generate with CONFIG_PREEMPT=y. A few weeks ago, I noticed the symptoms described in this thread where my desktop had some instances of delayed keyboard response, etc. Fortunately, the problem cleared before I had to try to find the faulty commit. The above paragraph was a long way to say that I do not believe the problem to be one of preempt configuration, but one of a kernel bug that has been fixed in mainline, but apparently not yet fixed in the openSUSE default kernel. If you are having the problem, I suggest that you try the Kernel_HEAD_standard tree and see if a 5.0.0-rcX kernel fixes your problem. Changing the preemption might make a difference, but that seems to be attacking symptoms, not causes. Larry -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2/6/2019 7:34 AM, Richard Brown wrote:
Hi all,
CONFIG_PREEMPT_NONE (as seen in SLE/Leap)
Really? the desktop distro Leap uses a config setting intended for servers and that is documented to give unreliable response time for interactive use? I'm guessing that it is set to that because that was originally all that was available, and as the kernel became more preemptable no one ever thought about what might be better for what I was told was, now, primarily a desktop distro?
CONFIG_PREEMPT (as in Tumbleweed right now) ?? how'd that get changed and what was the reasoning? Seems a bit intense.
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros)
Well, no wonder suse has a "reputation"... (that can be good and bad)....
I can understand the reluctance to change a kernel config option just because of a bug, Oh? On who's part? and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace.
--- That's a non-argument until the decision to go with the current choices is explained. I made a guess for the 1st, but how did the choice for TW get made? I'd like a pointer to the list archive where that was discusussed if possible (wondering if that might be considered too spiteful to even ask for?). Maybe considering what the defaults, according to the kernel authors...started with a 1-liner, and it sorta grew (attached and run in the base dir of a kernel source tree). Output:
config_info Archs: arc arm arm64 ia64 mips nds32 parisc powerpc s390 sh sparc x86 xtensa Choices: PREEMPT_VOLUNTARY PREEMPT PREEMPT_TRACER Choice PREEMPT_VOLUNTARY, count=27 Choice PREEMPT, count=114 Choice PREEMPT_TRACER, count=1
Ignoring TRACER since I've never seen it before and at a usage count of 1, it's an obvious outlier. :-), most used is preempt -- but none on x86. And seeming to be mostly on procs used for handhelds(?) Sub breakdowns: 7 arc PREEMPT 1 arc PREEMPT_VOLUNTARY 6 arc PREEMPT 19 arm PREEMPT 1 arm PREEMPT_VOLUNTARY 27 arm PREEMPT 1 arm PREEMPT_VOLUNTARY 1 arm PREEMPT 2 arm PREEMPT_VOLUNTARY 1 arm PREEMPT 1 arm64 PREEMPT 2 ia64 PREEMPT 1 mips PREEMPT 6 mips PREEMPT_VOLUNTARY 7 mips PREEMPT 2 mips PREEMPT_VOLUNTARY 1 mips PREEMPT 3 mips PREEMPT_VOLUNTARY 1 mips PREEMPT 1 mips PREEMPT_VOLUNTARY 2 mips PREEMPT 1 nds32 PREEMPT 2 parisc PREEMPT_VOLUNTARY 1 parisc PREEMPT 1 parisc PREEMPT_VOLUNTARY 3 powerpc PREEMPT 1 powerpc PREEMPT_VOLUNTARY 4 powerpc PREEMPT 1 s390 PREEMPT 1 s390 PREEMPT_TRACER 16 sh PREEMPT 2 sh PREEMPT_VOLUNTARY 6 sh PREEMPT 1 sh PREEMPT_VOLUNTARY 1 sh PREEMPT 1 sparc PREEMPT_VOLUNTARY 2 x86 PREEMPT_VOLUNTARY 5 xtensa PREEMPT The 2 counts for x86 were for 32 and 64 bit. Where only the Voluntary option is used. But what I feel is most important is to read the help in the kernel configurator when it is available (complete text from xconfig below (or in your kernel source). I read: No Forced Preemption (Server) (PREEMPT_NONE) (Select this option if you are building a kernel for a server or scientific/computation system...) Preemptible Kernel (Low-Latency Desktop) (PREEMPT) This allows applications to run more 'smoothly' even when the system is under load, at the cost of slightly lower throughput and a slight runtime overhead to kernel code. Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) (my rewording, otherwise couldn't summararize) "Voluntary" pre-emption points are added to allow the kernel to be interrupted when it is a reasonably good time to do so -- trading millisecond responsiveness for maybe 50-100ms (my estimate), but gaining little in lost efficiency in processing background loads. This allows smoother running even under loads. Those were my choices when the kernel first offered full preemption. Surprise -- I chose the *voluntary* option to maximize throughput, while adding enough flexibility for my own needs. I've tried full preempt, and I can sorta feel the overhead (in my imagination, most likely) even though everything is more interactive. I'm surprised by the current suse choices that seem to have been chosen almost by default -- maybe entirely -- i.e. -- with the least critical thinking and analysis, but in this case, I'm pretty sure even my parents would understand the choices. This is why keep trying to retain the ability to build my own kernel, I'm gonna go 1 farther than Richard. I suggest having BOTH Leap and TW going with Voluntary preemption. It makes the most sense for the most people. I can't think of anyone on this list who needs or would feel the difference between milliseconds and centiseconds. Full text for choices: ---------------------------------------------------------------- No Forced Preemption (Server) (PREEMPT_NONE) CONFIG_PREEMPT_NONE: This is the traditional Linux preemption model, geared towards throughput. It will still provide good latencies most of the time, but there are no guarantees and occasional longer delays are possible. Select this option if you are building a kernel for a server or scientific/computation system, or if you want to maximize the raw processing power of the kernel, irrespective of scheduling latencies. ---------------------------------------------------------------- Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) CONFIG_PREEMPT_VOLUNTARY: This option reduces the latency of the kernel by adding more "explicit preemption points" to the kernel code. These new preemption points have been selected to reduce the maximum latency of rescheduling, providing faster application reactions, at the cost of slightly lower throughput. This allows reaction to interactive events by allowing a low priority process to voluntarily preempt itself even if it is in kernel mode executing a system call. This allows applications to run more 'smoothly' even when the system is under load. ---------------------------------------------------------------- Preemptible Kernel (Low-Latency Desktop) (PREEMPT) CONFIG_PREEMPT: This option reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. This allows reaction to interactive events by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This allows applications to run more 'smoothly' even when the system is under load, at the cost of slightly lower throughput and a slight runtime overhead to kernel code. Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range. ===========================================================================
That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option.
---- More important than going for defaults is to make the choice and not go with the "no changes" attitude. In this case Suse chose the two most extreme options -- full preempt and no preempt, both of which can highlight the worst features of each model. Going with the middle path is really more important that doing nothing or going with defaults, _IMO_....
Therefore after this testing I'm convinced that CONFIG_PREEMPT_VOLUNTARY is a better default for the Tumbleweed kernel-default than the current CONFIG_PREEMPT
What do you all think?
That suse has only gone with the worst options (for server in desktop distro, and for lab-machine in the other distro) -- well... please think about this. This isn't a unique case. :-( Also, the idea of 'voluntary', has usually seemed like a good idea. Anything that bespeaks of some 1-wayism, is going toward convincing people not to think and make their own choices. I find it sad that so many not only accept that, but seem to want it. BTW -- the idea of decisions being made by those willing to make the decisions and work for them -- is an idea in common with dictators -- it's not what's good, best or smart for the most people. There's more info about how some of the those open-source "ethics" are commonly the most harmful to the most people. No surprise that Google had the same sexual environment as Uber -- but that google just had better (smarter) spin doctors. Sadly it seems that the computer+software worlds allow & promote an intensification of the worst traits of humanity. I.e. if someone is willing to push their way of doing things on others, but can program 100's of thousands or millions of CPU's to unthinkingly enforce the worst of humanity -- its not a bit surprise how outrageous behavior has quickly grown to become the 'norm' in behavior (and even be elected to offices as high as the US-presidency). I.e. I do agree w/your idea and have been using that in my kernel for over a decade. Thanks for bringing up the topic! #!/bin/bash #(in some linux dir, like 4.20.7...) Cfg_RE='CONFIG_PREEMPT(?:[_A-Z]+=)?' Cfg_paths="arch/+([^/])/configs" shopt -s expand_aliases # needed w/non-POSIX compliant shells (*cough*) alias my='declare ' array='my -a ' map='my -A ' array archs=() map -i choices=() map archs2choicesNcnts=() map archs2choices=() while read count arch choice; do archs2choicesNcnts[$arch]="$choice $count" archs2choices[$arch]+="$choice " choices["$choice"]+=$count done< <( grep -Pr "$Cfg_RE" $Cfg_paths | \ sed -r 's!configs/.*:!! s!arch/!! s!/CONFIG_PREEMPT! PREEMPT! s/=y//' | \ uniq -c ) # array sorted_archs=() readarray -t sorted_archs< <( printf "%s\n" "${!archs2choices[@]}" | sort) printf "Archs: %s\n" "${sorted_archs[*]}" printf "Choices: %s\n" "${!choices[*]}" for c in "${!choices[@]}"; do printf "Choice %s, count=%s\n" "$c" "${choices[$c]}" done
On Sat, 2019-02-09 at 15:50 -0800, L A Walsh wrote:
On 2/6/2019 7:34 AM, Richard Brown wrote:
Hi all,
CONFIG_PREEMPT_NONE (as seen in SLE/Leap)
Really? the desktop distro Leap uses a config setting intended for servers and that is documented to give unreliable response time for interactive use?
Shrug. Yes, worst case latency is higher than alternative models, but general case latency is fine, as it must must be, else servers couldn't use PREEMPT_NONE to service human interfacing clients. PREEMPT_NONE is just one of three trade-offs, each of the three a mixed bag of strength and weakness. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2/10/2019 11:04 PM, Mike Galbraith wrote:
On Sat, 2019-02-09 at 15:50 -0800, L A Walsh wrote:
On 2/6/2019 7:34 AM, Richard Brown wrote:
Hi all,
CONFIG_PREEMPT_NONE (as seen in SLE/Leap)
Really? the desktop distro Leap uses a config setting intended for servers and that is documented to give unreliable response time for interactive use?
Shrug. Yes, worst case latency is higher than alternative models, but general case latency is fine, as it must must be, else servers couldn't use PREEMPT_NONE to service human interfacing clients. PREEMPT_NONE is just one of three trade-offs, each of the three a mixed bag of strength and weakness.
-Mike
For a desktop user who might like to user their computer interactively and use it to play music or stream a video while they compile the kernel, which would be the recommended kernel model? As for using PREEMPT-NONE to service humans who in my parents generation used slide rules or an abacus, I'm sure tolerating delays under PREEMPT-NONE is hardly noticeable. But other people have a lower tolerance, to the point that anything over 100ms (full round trip) has people complaining about the slow ping times for a modern PvP game. In the same light, there would be a 'best' choice for someone recording live video needing a minimum of latency, and for computers run servicing storage or web requests or running as build machines 24/7, the most efficient kernel would also be a best choice. It really isn't based on averages over long periods, but in the case of real-time recording or needing fast response time having something set for no preemption isn't the best choice. That said -- if it is known something is causing worst case performance under PREEMPT_NONE, it should be fixed besides being run in a SW environment where it won't or can't show the bad behavior. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 2019-02-20 at 01:33 -0800, L A Walsh wrote:
For a desktop user who might like to user their computer interactively and use it to play music or stream a video while they compile the kernel, which would be the recommended kernel model?
Depends upon who's doing the recommending I suppose.. I prefer PREEMPT_VOLUNTARY, so would recommend that. (lecture elided) -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed 2019-02-20 01:33:11, L A Walsh wrote:
On 2/10/2019 11:04 PM, Mike Galbraith wrote:
On Sat, 2019-02-09 at 15:50 -0800, L A Walsh wrote:
On 2/6/2019 7:34 AM, Richard Brown wrote:
Hi all,
CONFIG_PREEMPT_NONE (as seen in SLE/Leap)
Really? the desktop distro Leap uses a config setting intended for servers and that is documented to give unreliable response time for interactive use?
Shrug. Yes, worst case latency is higher than alternative models, but general case latency is fine, as it must must be, else servers couldn't use PREEMPT_NONE to service human interfacing clients. PREEMPT_NONE is just one of three trade-offs, each of the three a mixed bag of strength and weakness.
-Mike
For a desktop user who might like to user their computer interactively and use it to play music or stream a video while they compile the kernel, which would be the recommended kernel model?
As for using PREEMPT-NONE to service humans who in my parents generation used slide rules or an abacus, I'm sure tolerating delays under PREEMPT-NONE is hardly noticeable. But other people have a lower tolerance, to the point that anything over 100ms (full round trip) has people complaining about the slow ping times for a modern PvP game.
This all sounds theoretical. It would be useful to provide some data from a real life scenario. I somehow doubt that playing PvP and compiling kernel at the same time is a common use case. Also I wonder if people noticed any any problems with PREEMPT-NONE before the GNOME bug. Best Regards, Petr -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 06 Feb 2019 16:34:02 +0100, Richard Brown wrote:
Hi all,
I was talking to Takashi lately about the saga that is bug 1112824
http://bugzilla.opensuse.org/show_bug.cgi?id=1112824
In that bug a kernel with CONFIG_PREEMPT_VOLUNTARY=y was provided, and a user reported that it did not improve the situation for them
However, as a heavy GNOME user, in my own testing, I have found the following results
CONFIG_PREEMPT_NONE (as seen in SLE/Leap) 'feels' slower, but is usable without the sort of stalls/hangs/inputs being dropped that are described in 1112824
CONFIG_PREEMPT (as in Tumbleweed right now) 'feels' faster than _NONE, mostly, but then interactive processes like many functions in GNOME randomly stall/hang with keyboard entries being dropped, as described in 1112824. IOW - I can reproduce the issues reported to a perceptible degree
CONFIG_PREEMPT_VOLUNTARY (as used in 'other distros) 'feels' just as fast as _PREEMPT, without the stalls in GNOME
I can understand the reluctance to change a kernel config option just because of a bug, and I do understand the argument than this bug could/should be fixed by GNOME doing less stupid stuff in userspace.
That said, I also think it's important that we should aim for defaults somewhat defensively - if _PREEMPT can cause such disruption due to badly written userspace behaviour, but _VOLUNTARY does not, then I think VOLUNTARY is a better option.
Therefore after this testing I'm convinced that CONFIG_PREEMPT_VOLUNTARY is a better default for the Tumbleweed kernel-default than the current CONFIG_PREEMPT
What do you all think?
Since we seem agreeing for this, I opened the bugzilla entry to track the change. https://bugzilla.opensuse.org/show_bug.cgi?id=1125004 Some of relevant people have been already put to Cc there. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (9)
-
Bruno Friedmann -
Guillaume Gardet -
L A Walsh -
Larry Finger -
Mike Galbraith -
Petr Mladek -
Richard Brown -
Takashi Iwai -
Wolfgang Rosenauer