Thread scheduling in linux

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

This a repository containing use of Linux Scheduling policies for three threads, three process. The last part includes a simple syscall implementation in Linux.

Ashutosh-Gera/Linux-Process-and-Thread-Scheduling

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

This repository has three folders. One demonstrates using Linux scheduling policies to schedule 3 threads running parallely. Second is using Linux Scheduling policies to demonstrate process scheduling among 3 parallel processes. Third is the implementation of a Custom Syscall in Linux.

Below are the explainations for each of them:

I am launching three threads, each of which relies on three different functions, countA(), countB() and countC() respectively. Each function does the same thing, i.e. counts from 1 – 2^32. The following is the detailed specification of each of the threads, to being with:

1. Thread 1 (Thr-A()): Uses SCHED OTHER scheduling discipline with standard priority (nice:0).
2. Thread 2 (Thr-B()): Uses SCHED RR scheduling discipline with default priority.
3. Thread 3 (Thr-C()): Uses SCHED FIFO scheduling discipline with default priority.

Each of these threads times the process of counting from 1 – 2^32. I have used the clock gettime() function for obtaining the actual time ticks that have been used to compute how long it took to complete a function.

After that, I am benchmarking these three schedulers by changing the scheduling classes of the three threads (keeping the other scheduling priorities the same), against the counting program.

For these cases, I am using pthread schedsetparam() and related functions for the same. After running a test whose outputs have been stored in the files thrA.txt, thrB.txt, thrC.txt respectively, I am generating histograms [file named plot.ipynb] showing which scheduler completes the task when, depending upon the scheduling policy.

I have chosen different colors for the histogram bars, with one axis showing the time to complete, and the other showing the thread priorities. For our benchmarking, we have chosen 10 values each.

To run this on your system:

• Clone the repository
• Open the «threadScheduling» directory
• Run make
• Input the priority values that you need to mention for each of the threads, and, enjoy 🙂

Note: A key difference between linux thread scheduling policies is that for the policies SCHED_RR and SCHED_FIFO the priority value is can be set by us. Whereas for the scheduling policy SCHED_OTHER, priority is always default (i.e. 0) and we only change the nice value associated with it.

This part involves creating three process, instead of the three threads. Each of these process involves compiling a copy of the Linux kernel source (with the minimal config, download by clicking here). The three processes are created with fork() and thereafter the child processes is using the execl() family system calls to run a different a different bash script(namely scriptA.sh, scriptB.sh and scriptC.sh), each of which comprises of the commands to compile a copy of the kernel. To time the execution, the parent process is getting the clock timestamp (using clock gettime()) before the fork and after each process terminates returns.

After running the three compiling processes parallely, we get the time value taken by each scheduling policies and plot a histogram using those values [present in the file plot2.ipynb file].

To compile the linux kernel using this process scheduling and scripts, follow the following steps:

• Have the linux kernel [whichever version u want to be compiled] downloaded in your VM.
• Make 3 directories namely «a», «b» and «c» respectively.
• Make sure the un-tar file of linux kernel is present in each of these directories.
• Run make outside these directories and bingo! you’ll have 3 linux kernels being compiled simultaneously in your VM.

Key-point: In order to run the 3 processes paraellely and also to track the time taken by each process to complete, we were required 5 fork() calls.

Firstly add the new syscall to the table of already existing syscalls in build/linux-5.xx.xx/arch/x86/entry/syscalls/syscall_64.tbl add

451 kern_2D_memcpy sys_kern_2D_memcpy 

Then implement the same syscall in sys.c located at buiild/linux-5.xx.xx/kernal/sys.c

Where we define the following function

SYSCALL_DEFINE4(kern_2D_memcpy, float *, MAT1, float *, MAT2, int, ROW, int, COL) 

We take the pointers to the two float matrices where MAT1 is the destination matrix and MAT2 is the source matrix. We create a new matrix of dimensions ROWxCOL in the kernel space to which we then copy the contents of MAT2 using copy_from_user and then we copy it to MAT1 using copy_to_user If any of the above are not possible we return -EFAULT else return 0 incase of success.

Building/Compiling the syscall

After adding the syscalls we need to run the following commands to configure our kernel

make make modules_install cp arch/x86_64/boot/bzImage /boot/vmlinuz-linux-5.19.9-gb0ccfee715-dirty cp System-5.19.9.map System-5.19.9-gb0ccfee715-dirty.map mkinitcpio -k 5.19.9-gb0ccfee715-dirty -g /boot/initramfs-linux-5.19.9-gb0ccfee715-dirty.img grub-mkconfig -o /boot/grub/grub.cfg reboot 

Make the test files in any directory and then run

Note: Each of the folders have a readMe.txt of their own too, inside. You can use those for further reference.

Thank you for visiting. Hope it helps.

Made with 💙 by Ashutosh Gera

About

This a repository containing use of Linux Scheduling policies for three threads, three process. The last part includes a simple syscall implementation in Linux.

Источник

Does linux schedule a process or a thread?

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.

2 Answers 2

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

• 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

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?

@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.

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

Источник

How Linux handles threads and process scheduling

I’m trying to understand how Linux handles process scheduling and thread scheduling. I read that Linux can schedule both processes and threads. Does Linux have a thread scheduler AND a process scheduler? If yes, how do they cooperate?

I’m speaking in general , about kernel threads not user threads. I don’t know what’s a thread library .

3 Answers 3

The Linux kernel scheduler is actually scheduling tasks, and these are either threads or (single-threaded) processes.

So a task (a task_struct inside the kernel), in the context of the scheduler, is the thing being scheduled, and can be some kernel thread like kworker or kswapd , some user thread of a multi-threaded process (like firefox ), or the single-thread of a single-threaded process (like bash ), identified with that single-threaded process.

A process is a non-empty finite set (sometimes a singleton) of threads sharing the same virtual address space (and other things like file descriptors, working directory, etc etc. ). See also credentials(7), capabilities(7) etc.

Threads on Linux are kernel threads (in the sense of being managed by the kernel, which also creates its own threads), created by the Linux specific clone syscall (which can also be used to create processes on Linux). The pthread_create function is probably built (on Linux) above clone inside NPTL and Gnu Libc (which integrated NPTL on Linux) and musl-libc.

Источник