"cooperative multitasking" in user space versus "preemptive multitasking" in kernel?
 

Hi:

I have a fundamental question regarding the current Linux kernel/scheduler and impact upon SMP architecture.

Say I have a simple program that spawns two threads. Each thread contains two lines of code that will spike the CPU usage of a particular CPU to 100%:

while(1)
sqrt(rand());

There is not any user space code with any sort of "yield" allowing other processes to run upon a particular CPU, the thread simply contains the above while() loop that with the random number causes caching not to be effective and thus CPU usage is 100%.

If I run the program and then invoke the "htop" utility, I see the threads bouncing around from CPU to CPU as the load balancer within the kernel tries to optimize performance.

So this completely a user space program. When we say Linux kernel version 2.6+ supports preemption, its not just threads within the kernel, the kernel may preempted user space as well - is this true? I could be getting load balancing of threads within user space confused with kernel preemption... Google has resulted in conflicting data (at least what I've found regarding Linux kernel preemption and effects upon user space code.

"Cooperative multitasking" in user space versus "preemptive multitasking" in kernel description seems to be inaccurate as I see the kernel processor balancing the user space threads. Could someone set me straight and these basic user space/kernel space/load balancing/preemption concepts?

Thanks!

The kernel perceives that it has a 100%-CPU-busy process on its hands. It's consuming full time-slices every time without generating any I/O. Different CPUs, more or less at random, are picking it up because presumably they have very little else to do. You'll see this process receiving automatically-lowered priorities, and the system is attempting to arrange for the process to have the full time-slices that it apparently needs. The CPUs understand that a process of this sort is perfect for "look-busy work," something that lets them score near-100% CPU utilization instead of twiddling their silicon thumbs.

"Kernel thread pre-emption" is strictly a kernel design issue: it refers to the ability of the kernel to not only delegate parts of its own activities to very privileged "part of the kernel" threads of its own making, but also to permit those threads to be pre-empted. The kernel, of course, is sovereign, and it implicitly trusts itself. Its designers deign to specify certain kernel functionality as "a thread," because it is convenient to do so, and they furthermore have seen fit to allow certain of those threads to permit themselves to be pre-empted by incoming interruptions.

So, kernel thread pre-emption has nothing per se to do with user-space process preemption ... except that both types of threads are now being subject to the same ability to be pre-empted.

User-land processes have no choice in the matter: they are pre-emptible, even if they're running endless loops. (They can, within their own process contexts, implement a cooperative-multitasking scheme, and there are many choices for doing just that, but the entire process context is nevertheless subject to pre-emption by the kernel.)

Thank you for the reply.

So it sounds like the content within this article is not accurate, regarding user space threads and "These threads follow co-operative multitasking where-in a thread releases CPU on its own wish ie the scheduler cannot preempt the thread." Is my understanding correct?:

http://www.thegeekstuff.com/2012/03/...threads-intro/

User threads Vs Kernel Threads

Threads can exist in user space as well as in kernel space.

A user space threads are created, controlled and destroyed using user space thread libraries. These threads are not known to kernel and hence kernel is nowhere involved in their processing. These threads follow co-operative multitasking where-in a thread releases CPU on its own wish ie the scheduler cannot preempt the thread. Th advantages of user space threads is that the switching between two threads does not involve much overhead and is generally very fast while on the negative side since these threads follow co-operative multitasking so if one thread gets block the whole process gets blocked.

A kernel space thread is created, controlled and destroyed by the kernel. For every thread that exists in user space there is a corresponding kernel thread. Since these threads are managed by kernel so they follow preemptive multitasking where-in the scheduler can preempt a thread in execution with a higher priority thread which is ready for execution. The major advantage of kernel threads is that even if one of the thread gets blocked the whole process is not blocked as kernel threads follow preemptive scheduling while on the negative side the context switch is not very fast as compared to user space threads.