PREEMPT_NONE — No forced preemption (server) wrote:
This is the traditional Linux preemption model, geared toward maximizing throughput. It still provides good latency most of the time, 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.
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, which provides faster response to applications at the cost of slighly lower throughput.
This option speeds up 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 appear to run more smoothly even when the system is under load.
Select this if you are building a kernel for a desktop system.
This option reduces the latency of the kernel by making all kernel code (except code 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 appear to run more smoothly even when the system is under load, at the cost of slighly 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.
... 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.
And at the cost of screwing up the FPU stack, it would seem.
Note the "low priority process". BOINC apps run at low priority, and so if this option is set the BOINC app may be preempted, which may screw up a floating point calculation.
This option should only be set for embedded systems or systems which require really low latency, as for high-end audio or video processing. I would hope that Ubuntu would use voluntary preemption, and I would guess Fedora would use none, since they focus on servers.
To know how big a problem this is it would be helpful to know, for every signal 8 error, the Linux distribution involved, and the kernel version.
If you have /proc/config.gz it would be useful to check it.
If you build your own kernel, use voluntary preemption.
I was just going through my own kernel configuration and I see that the low-latency option was the default. So that's something to watch out for.
there
are runtime /proc/sys knobs and boot-time flags to turn voluntary
preemption (CONFIG_VOLUNTARY_PREEMPT) and kernel preemption
(CONFIG_PREEMPT) on/off:
it MAY, but imho its not likely. I have an alternate theory for your problem: Thoroughbred core and SSE support.
Looking at your failed WU, your computer is trying tro use the _1 app, thats the SSE one.
Is your core a Thoroughbred? Family 6 Model 8 it says, i think a Barton 2600+ would show up as Family 6 Model 10. Been a while since i had Athlon XP now, and even longer since i had XP with Thoroughbred core, but i remember people had problems at the time, one guy even got the error "No SSE support" in a game and the problem went away when he flashed his motherboard BIOS to the latest version. I would look into that matter, even if the combination of Bios and SSE support doesnt really make sense at all its not a secret that AMD had poor SSE implementation in early core revisions.
Anyone else had problems with SSE apps for E@H and Thoroughbred cores?
The nice thing about the idea that it is the preemption setting is that it is a testable hypothesis. He can make the changes described above and crunch some more, and if that fixes the problem then it was preemption, If not, it wasn't.
Here is another interesting bit of info. In January both Norm and I tried to run E@H on XO laptops (see this thread), but the WU's would fail with signal 8. I just checked, and it seems the kernel there may also be set with PREEMPT=y. There are no adjustable settings in /proc/sys/kernel for preemption, but /proc/sys/kernel/version shows
#1 PREEMPT Wed Nov 21 00:39:06 EST 2007
So it may be that the premptable kernel option is also the problem on the XO laptop. I'll have to see if I can change that setting as a boot option.
Another user, J.Mell, has invested great efforts into hunting down this CONFIG_PREEMPT=y hypothesis and his findings are really unambiguous: If you have a Linux kernel >= 2.6.20 and <= 2.6.26, compiled with CONFIG_PREEMPT=y, you WILL encounter this problem sooner or later (rather sooner...). At the moment it seems that a fix to a certain Linux kernel bug that (I guess) was discovered independently may also happen to fix this problem.
Ok guys, I think it's obviously the kernel bug Ageless brought into play. I tried to use the kernel-preempt=0 boot parameter, which brought no help but lead to a weird behavior of the system (as if it would only do batch jobs without timesharing/multitasking). Preemtion is important, I can tell. :-D
So what I've done is to build a new kernel via Arch Build System with the option CONFIG_PREEMPT=n (also ugly systems behavior) and that fixed it. Einstein has completed its first package since a long time, so I have no doubt about that the kernel bug is the problem here.
I think that thing can savely be added into the FAQ. Thanks for your help guys.
About that PREEMPT_VOLUNTARY thing: I don't know if I really want this. As I read this, the option is between PREEMPT_NONE and PREEMPT, right? Wouldn't this just bring the error back and also longer times of reaction? Or is it really save? I mean, I'm going to give it a try but testing takes a while.
I think that thing can savely be added into the FAQ. Thanks for your help guys.
I'll be writing it, but going at it slowly, as I don't think this will fix it for every Linux distro. No doubt it's the cause on your constant signal 8 errors, but what of people who run into it once in a while?
I think we may need some more investigation into it.
See Kernel Configuration
)
See Kernel Configuration options for what they mean.
Ageless wrote: PREEMPT —
)
And at the cost of screwing up the FPU stack, it would seem.
Note the "low priority process". BOINC apps run at low priority, and so if this option is set the BOINC app may be preempted, which may screw up a floating point calculation.
This option should only be set for embedded systems or systems which require really low latency, as for high-end audio or video processing. I would hope that Ubuntu would use voluntary preemption, and I would guess Fedora would use none, since they focus on servers.
To know how big a problem this is it would be helpful to know, for every signal 8 error, the Linux distribution involved, and the kernel version.
If you have /proc/config.gz it would be useful to check it.
If you build your own kernel, use voluntary preemption.
I was just going through my own kernel configuration and I see that the low-latency option was the default. So that's something to watch out for.
- Eric Myers
See also this kerneltrap
)
See also this kerneltrap thread:
it MAY, but imho its not
)
it MAY, but imho its not likely. I have an alternate theory for your problem: Thoroughbred core and SSE support.
Looking at your failed WU, your computer is trying tro use the _1 app, thats the SSE one.
Is your core a Thoroughbred? Family 6 Model 8 it says, i think a Barton 2600+ would show up as Family 6 Model 10. Been a while since i had Athlon XP now, and even longer since i had XP with Thoroughbred core, but i remember people had problems at the time, one guy even got the error "No SSE support" in a game and the problem went away when he flashed his motherboard BIOS to the latest version. I would look into that matter, even if the combination of Bios and SSE support doesnt really make sense at all its not a secret that AMD had poor SSE implementation in early core revisions.
Anyone else had problems with SSE apps for E@H and Thoroughbred cores?
Team Philippines
th3 wrote:it MAY, but imho
)
The nice thing about the idea that it is the preemption setting is that it is a testable hypothesis. He can make the changes described above and crunch some more, and if that fixes the problem then it was preemption, If not, it wasn't.
But testing alternative hypotheses is also good.
- Eric Myers
Here is another interesting
)
Here is another interesting bit of info. In January both Norm and I tried to run E@H on XO laptops (see this thread), but the WU's would fail with signal 8. I just checked, and it seems the kernel there may also be set with PREEMPT=y. There are no adjustable settings in /proc/sys/kernel for preemption, but /proc/sys/kernel/version shows
So it may be that the premptable kernel option is also the problem on the XO laptop. I'll have to see if I can change that setting as a boot option.
- Eric Myers
Hi all! Another user,
)
Hi all!
Another user, J.Mell, has invested great efforts into hunting down this CONFIG_PREEMPT=y hypothesis and his findings are really unambiguous: If you have a Linux kernel >= 2.6.20 and <= 2.6.26, compiled with CONFIG_PREEMPT=y, you WILL encounter this problem sooner or later (rather sooner...). At the moment it seems that a fix to a certain Linux kernel bug that (I guess) was discovered independently may also happen to fix this problem.
CU
Bikeman
Ok guys, I think it's
)
Ok guys, I think it's obviously the kernel bug Ageless brought into play. I tried to use the kernel-preempt=0 boot parameter, which brought no help but lead to a weird behavior of the system (as if it would only do batch jobs without timesharing/multitasking). Preemtion is important, I can tell. :-D
So what I've done is to build a new kernel via Arch Build System with the option
CONFIG_PREEMPT=n (also ugly systems behavior) and that fixed it. Einstein has completed its first package since a long time, so I have no doubt about that the kernel bug is the problem here.
I think that thing can savely be added into the FAQ. Thanks for your help guys.
About that PREEMPT_VOLUNTARY thing: I don't know if I really want this. As I read this, the option is between PREEMPT_NONE and PREEMPT, right? Wouldn't this just bring the error back and also longer times of reaction? Or is it really save? I mean, I'm going to give it a try but testing takes a while.
Hi! CONFIG_PREEMPT_VOLUNTA
)
Hi!
CONFIG_PREEMPT_VOLUNTARY is reported to be safe wrt. this issue.
For an in-depth discussion of this kernel bug and a proposed fix (which is submitted but not yet offical) you might find this instructive:
http://lkml.org/lkml/2008/6/1/34
CU
Bikeman
RE: I think that thing can
)
I'll be writing it, but going at it slowly, as I don't think this will fix it for every Linux distro. No doubt it's the cause on your constant signal 8 errors, but what of people who run into it once in a while?
I think we may need some more investigation into it.