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