Does linux schedule a process or a thread?

Question

After reading this SO question I got a few doubts. Please help in understanding.

Scheduling involves deciding when to run a process and for what quantum of time.

1. Does linux kernel schedule a thread or a process? As process and thread are not differentiated inside kernel how a scheduler treats them?

2. How quantum for each thread is decided? a. If a quantum of time (say 100us) is decided for a process is that getting shared between all the threads of the process? or b. A quantum for each thread is decided by the scheduler?

Note: Questions 1 and 2 are related and may look the same but just wanted to be clear on how things are working posted them both here.

Solution 1

The Linux scheduler (on recent Linux kernels, e.g. 3.0 at least) is scheduling schedulable tasks or simply tasks.

A task may be :

• a single-threaded process (e.g. created by fork without any thread library)
• any thread inside a multi-threaded process (including its main thread), in particular Posix threads (pthreads)
• kernel tasks, which are started internally in the kernel and stay in kernel land (e.g. kworker, nfsiod, kjournald , kauditd, kswapd etc etc...)

In other words, threads inside multi-threaded processes are scheduled like non-threaded -i.e. single threaded- processes.

The low-level clone(2) syscall creates user-land schedulable tasks (and can be used both for creating fork-ed process or for implementation of thread libraries, like pthread). Unless you are a low-level thread library implementor, you don't want to use clone directly.

AFAIK, for multi-threaded processes, the kernel is (almost) not scheduling the process, but each individual thread inside (including the main thread).

^{Actually, there is some notion of thread groups and affinity in the scheduling, but I don't know them well}

These days, processors have generally more than one core, and each core is running a task (at some given instant) so you do have several tasks running in parallel.

CPU quantum times are given to tasks, not to processes

Solution 2

The NPTL implementation of POSIX thread specifications sees thread as a different process inside kernel, having unique task_struct (and therefore pid too) so each thread is schedulable in itself as mentioned. Therefore each thread gets its own timeslice and is scheduled just like processes as mentioned above.

Just to add, Currently Linux scheduler is also capable of scheduling not only single tasks ( a simple process), but groups of processes or even users ( all processes, belonging to a user) as a whole. This allows implementing of group scheduling, where CPU time is first divided between process groups and then distributed within those groups to single threads.

Linux threads does not directly operate on processes or threads, but works with schedulable entities. Represented by struct sched_entity. It's fair to say that every process/thread is a sched_entity but the converse might not be true.

To know detailed process scheduling, refer here

Comments

[prasannatsm]

People say Linux schedules process while windows schedule threads. What is meant by that? As per this answer it looks like Linux schedules tasks (can be considered as threads) and windows does the same. Or Am I missing something?

[SecurityMatt]

@prasannatsm: I don't know about Linux, but Windows certainly only schedules threads. During any schedule operation, Windows chooses a "next thread" from a list of all running threads that have processor affinity, and context switches to it. Other than performing the CR3 switch, the scheduler does not look at processes for the purposes of choosing the next thread to run on the core.