# Preemption Model - Preemptible Kernel [SOLVED]

## dothedrew

Hi everyones!

I discovered recently, that I can turn on the option Preemption Model in the kernel config to increasing the speed. Actually, i'm using the option No Forced Preemption, and it's working good. But, I've tried to turn this option to Preemptible Kernel and I have a problem:  beryl is crashing. 

A also emerged the last instable version of the kernel (2.6.20-r2) and it does the same thing. Even ,if I changed the value of Preemption, Bery is always crashing with this kernel...

Does anybody, can tell me more about this option and why my computer seems to be unstable..?

ThankLast edited by dothedrew on Thu Mar 15, 2007 10:09 pm; edited 1 time in total

----------

## Crenshaw

Changing Preemption Model will not incerase speed of your computer. Preemptible kernel can "interrupt" (== preempt) tasks with lower priority to run tasks with higher prirority and this does not incerase total speed so if youre using no forced preemption and it's comfortable I think you should stick to it.  :Wink: 

----------

## widremann

 *Crenshaw wrote:*   

> Changing Preemption Model will not incerase speed of your computer. Preemptible kernel can "interrupt" (== preempt) tasks with lower priority to run tasks with higher prirority and this does not incerase total speed so if youre using no forced preemption and it's comfortable I think you should stick to it. 

 

Yes, it doesn't change the speed, per se, but it does change the responsiveness of applications, especially under heavier load.

You are wrong in your description of how this option works.  It doesn't have anything to do with preempting lower priority tasks.  Rather, it simply means that tasks that are running in kernel mode can be preempted.  Without this option enabled, once a process enters kernel mode via a syscall or an interrupt, it owns the CPU unless it voluntarily gives it up.  With this option enabled, it can be preempted even when running in kernel mode, allowing another process to run that may be more suitable to run.  For example, if an interrupt occurs because the mouse was moved, and the X server isn't the current process, then it would make sense to go ahead and immediately wake up the X server rather than waiting for the currently running process to complete whatever it is doing in the kernel.  This is, of course, an oversimplification.  But in general, it means that you don't defer task switches unnecessarily long, thus increasing responsiveness and decreasing (some) latency in the kernel.

----------

## d2_racing

 *dothedrew wrote:*   

> Actually, i'm using the option No Forced Preemption, and it's working good. But, I've tried to turn this option to Preemptible Kernel and I have a problem:  beryl is crashing. 
> 
> A also emerged the last instable version of the kernel (2.6.20-r2) and it does the same thing. Even ,if I changed the value of Preemption, Bery is always crashing with this kernel...
> 
> Does anybody, can tell me more about this option and why my computer seems to be unstable..?
> ...

 

I was there when he had that crash.

I recompiled his kernel with Preemption Model(Preemptible Kernel (Low-Latency Desktop)), and it crashed badly.

I also ran this just to make sure that everything was clean :

```

#cd /usr/src/linux

#cp /usr/src/linux/.config /boot/config-2.6.19-Gentoo-r5.config

# make clean

# make proper

# cp /boot/config-2.6.19-Gentoo-r5.config /usr/src/linux/.config

I actived the Preemptible Kernel

# make && make modules_install

Install the necessary

#reboot

```

I saw that his wifi driver ipw3945 didn't like the new kernel, because it's like alsa-driver, each time your recompile you need to reemerge that package...right ?

So, his computer started and Beryl(KDE) was very very slow.(Way to slow in fact)

I know that when he doesn't use Beryl, his KDE is lightning fast, so what can cause this problem ?

Finally, he rebuilded his kernel Preemptible Kernel at Server and his KDE is back to normal even when Beryl is active.

What is going on ????

----------

## dothedrew

Thanx for the explications guys, now I understand better what it is... I think this option should turn on, to have a better reactivity... 

But, this option seems to influence the beheviour of some applications. For example, after recompiling the kernel with the option on, my ipw3945 wireless driver wont load correctly, I have to recompile the driver to make it working again. The Preemptible option is related to the compilation!? Maybe I need something else in my kernel to deal with the preemptible option...

About my beryl problem, I cannot explain why this option making beryl crashing... anybody knows!!!

----------

## d2_racing

Can you post the result of glxinfo and glxgears when your Beryl if working fine and also when he crash ??

----------

## wynn

 *dothedrew wrote:*   

> But, this option seems to influence the beheviour of some applications. For example, after recompiling the kernel with the option on, my ipw3945 wireless driver wont load correctly, I have to recompile the driver to make it working again. The Preemptible option is related to the compilation!?

 From http://lwn.net/Articles/21454/ *Quote:*   

> All loadable modules now need to go through a linking step - even those which are built from a single source file. The link brings in init/vermagic.o from the kernel source tree; this object creates a special section in the loadable module describing the environment in which it was built. It includes the compiler version used, whether the kernel was built for SMP, whether kernel preemption is enabled, the architecture which was compiled for, and, of course, the kernel version. A difference in any of these parameters can render a module incompatible with a given running kernel; rather than fail in mysterious ways, the new module loader opts to detect these compatibilities and refuse to load the module.

 This describes the kernel vermagic string (the text dates from the 2.5.x series) which is in every module and is checked by the kernel when the module is loaded. As you can see, it includes "whether kernel preemption is enabled".

A change in the kernel configuration which changes one of the above settings means that all modules have to be recompiled.

The module vermagic string can be seen by

```
# modinfo -F vermagic nvidia

2.6.20-gentoo-r2 SMP mod_unload PENTIUM4
```

the kernel vermagic string is harder to display, see "FATAL: invalid module format" and vermagic

----------

## Crenshaw

 *widremann wrote:*   

>  *Crenshaw wrote:*   You are wrong in your description of how this option works.  It doesn't have anything to do with preempting lower priority tasks.  

 

I do not see how I contradict things that are here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/smp-design.html "Implementing full kernel preemption is very straightforward: when you schedule a thread to be executed by putting it on a run queue, you check to see if its priority is higher than the currently executing thread. If so, you initiate a context switch to that thread." here: http://en.wikipedia.org/wiki/Preemption_(computing). Could you tell me?

----------

## dothedrew

OK, now it is very clear! I understand why I need to recompile the external modules.

And I found the solution of my Bery problem! The problem was xorg enable to load DRI module. After compiling my new 2.6.20-r2 kernel, I started using the DRM support from the kernel as a module. I forgot to add the i915 module in the DRM section.

```
Devices Drivers

  Character Devices 

      Direct Rendering Manager
```

The migration to kernel 2.6.20 is completed! Thanx to everybody for the support!

----------

## d2_racing

Now, you just need to remove the ATAPI section and use the new SATA/PATA section.

To do this, please read this thread : https://forums.gentoo.org/viewtopic-t-537957.html

----------

## widremann

 *Crenshaw wrote:*   

>  *widremann wrote:*    *Crenshaw wrote:*   You are wrong in your description of how this option works.  It doesn't have anything to do with preempting lower priority tasks.   
> 
> I do not see how I contradict things that are here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/smp-design.html "Implementing full kernel preemption is very straightforward: when you schedule a thread to be executed by putting it on a run queue, you check to see if its priority is higher than the currently executing thread. If so, you initiate a context switch to that thread." here: http://en.wikipedia.org/wiki/Preemption_(computing). Could you tell me?

 

It's not that you're wrong about preemption...it's that you are wrong about what "preemptible kernel" means.  As I said above, it basically means that processes running in kernel mode can be arbitrarily preempted.  Under the old model, once a process entered kernel mode via, e.g., a system call, the only time another process could be scheduled to run was when the first process was about to make the switch back into userspace, or if that process explicitly yielded the CPU.  Thus, if the process took a long time to do things in the kernel, it could block other more worthy processes from running.  Under the new model, it can be preempted, even when in the kernel.

Note that processes running in user mode can *ALWAYS* be preempted.  That has not changed.  The only thing that has changed is preemptibility inside the kernel itself.

----------

## d2_racing

Thanks for theses links, I always learning something when I surf this forum  :Smile: 

----------

