Like in process management and memory management.
Are the scheduler and memory manager implemented as kernel threads that are run on the cpu the moment they are needed? If not, how does the kernel treat them?
Are they like processes, tasks, or some line of code that gets executed when needed?
Some are, some aren't. The terms "process management" and "memory management" are kind of broad and cover a fair bit of kernel code.
For memory management, a call to mmap() will just require changing some data structures and can be done by the current thread, but if pages are swapped out it will be done by kswapd, which is a kernel thread.
You might consider the scheduler a special case: since the scheduler is responsible for scheduling all threads, it itself is not a thread and does not execute on any thread (otherwise it would need to schedule itself... but how would it schedule itself, if it had to schedule itself first in order to do that?). You might think of the scheduler as running directly on each processor core when necessary.
Related
I'm a kernel noob including schedulers. I understand that there is a IO scheduler and a task scheduler and according to this post IO scheduler uses normal tasks that are handled by the task schedule in the end.
So if I run an user space thread that was assigned to an isolated core (using isolcpus) and it will do some IO operation, will the the
task created by the IO scheduler get executed on the isolated core ?
Since CFS seems to favor user interaction does this mean that CPU intensive threads might get a lower CPU time in the long run?
Isolating cores can help mitigate this issue?
Isolating cores can decrease the scheduling latency (the time it takes for a thread that was marked as runnable to get executed ) for
the threads that are pined to the isolated cores?
So if I run an user space thread that was assigned to an isolated core
(using isolcpus) and it will do some IO operation, will the the task
created by the IO scheduler get executed on the isolated core ?
What isolcpus is doing is taking that particular core out of kernel list of cpu where it can schedule tasks. So once you isolate a cpu from kernel's list of cpus it will never schedule any task on that core, no matter whether that core is idle or is being used by some other process/thread.
Since CFS seems to favor user interaction does this mean that CPU
intensive threads might get a lower CPU time in the long run?
Isolating cores can help mitigate this issue?
Isolating cpu has a different use altogether in my opinion. Basically if your applications has both fast threads(threads with no system calls, and are latency sensitive) and slow threads(threads with system calls) you would want to have dedicated cpu cores for your fast threads so that they are not interrupted by kernel's scheduling process and hence can run to their completion without any noise. Fast threads are usually latency sensitive. On the other hand slow threads or threads which are not really latency sensitive and are doing supporting logic for your application need not have dedicated cpu cores. As mentioned earlier isloting cpu servers a different purpose. We do all this all the time in our organization.
Isolating cores can decrease the scheduling latency (the time it takes
for a thread that was marked as runnable to get executed ) for the
threads that are pined to the isolated cores?
Since you are taking cpus from kernel's list of cpus this will surely impact other threads and processes, but then again you would want to pay extra thought and attention to what really is your latency sensitive code and you would want to separate it from your non-latency sensitive code.
Hope it helps.
I recently stumbled upon the question above but I am not sure if I understand what it is asking.
How would one avoid the use of scheduling policies?
I would think that there isn't any other way...
Scheduling policy has nothing to do with the resource allocation! Processes are scheduled basically, and hence allocated resources as such.
From "Resource allocation (computer)" description on Wikipedia :-
When the user opens any program this will be counted as a process, and
therefore requires the computer to allocate certain resources for it
to be able to run. Such resources could have access to a section of
the computer's memory, data in a device interface buffer, one or more
files, or the required amount of processing power.
I don't know how you got confused between them. All the process would, at a time or another, get scheduled at any point of time; unless the CPU is an unfair one.
EDIT :
How would one avoid the use of scheduling policies?
If there are more than one user-process to be executed, then one has to apply the scheduling policy so that the processes get executed in some order. There has to be a queue to hold all the processes. See a different case in BareMetal OS below.
Then, there is BareMetal OS which is single address space OS.
Multitasking on BareMetal is unusual for operating systems in this day
and age. BareMetal uses an internal work queue that all CPU cores
poll. A task added to the work queue will be processed by any
available CPU core in the system and will execute until completion,
which results in no context switch overhead.
So, BareMetal OS doesn't use any scheduling policy, it is based on polling of the work-queue by the cores.
I would like to run a single low latency task (for audio, ALSA/JACK) on a separate core with an embedded Linux system. Removing scheduler and other interrupts might be the key here.
There were several approaches I found so far, e.g. cpusets and an offline scheduler from 2009 (which unfortunately does not support user space tasks).
Is there a newer/more convenient way to achieve this?
Offline scheduler
The topic you are looking for is called "CPU affinity". There are two main aspects to the CPU affinity: affinity of processes and affinity of the interrupts.
To my (admittedly limited) knowledge:
The processes are assigned to CPUs using the taskset command. (The affinity is inherited by the child processes.)
The interrupts to CPU assignment on Linux can be manipulated using the /proc/irq/<n>/smp_affinity. To verify the effectiveness of the assignment, check the /proc/interrupts to see which CPUs serve which interrupts. See here.
In your particular case, you want to reserve a single CPU (aka core) for your critical application, for example CPU0. That means that all processes and interrupts should be assigned to all but the CPU0, using the affinity mask which has the bit 0 (== CPU0) cleared, e.g. 0xfffffffe. And your critical application would have the affinity mask of 0x1, meaning that it is allowed to run only on the CPU0.
Additionally, you might need to use the sched_setscheduler syscall in the application to set the scheduling to one of the real-time policies. That might improve the latencies of your application (but also can make worse).
Note that tuning the CPU affinity is not a trivial endeavor and clear-cut solutions are rare. You would need to test and experiment to make sure that the configuration can sustain the performance you need. For example, it is likely that your application would communicate with the other processes. If the communication is synchronous, and the other processes are slow to react (since they have limited CPU resources), that would in turn negatively impact performance of your critical application. Same applies to the interrupt(s) of the sound card.
Hope that helps.
What are user threads? Below explanation says they are managed by userspace... Please explain how?
Threads are sometimes implemented in userspace libraries, thus called user threads. The kernel is not aware of them, so they are managed and scheduled in userspace.
Every modern server or desktop OS, and all major mobile OSs, have a native thread library these days, so this question is not very relevant anymore. But basically, before this was the case, there were libraries -- most famously, the "Green threads library" -- which implemented cooperatively-multitasking threads as a user library. That "cooperatively multitasking" part is the important part: in general, such a library switches from one thread to another only when the thread calls some method that allows a switch to happen ("sleep", "yield", etc.) A user library generally can't do preemptive time-slicing; that's something that has to be done at the OS level.
Symbian OS has an Active Object framework that allows async event handling in a single thread
http://en.wikipedia.org/wiki/Active_object_%28Symbian_OS%29
Windows also has Fibres:
http://msdn.microsoft.com/en-us/library/ms682661%28v=vs.85%29.aspx
Kernel threads (also called lightweight process) are handeled by the system. They offer several interesting benefits, the main one being that two threads can be scheduled on two different processors in the hope that this will reduce the execution time of your process.
However threads are often used as a programming model. A typical example is a multi-client webserver that waits for incoming connexion and simultaneously exchange data with its connected clients. In this case the programmer may want to create a lot of threads and switch between them very quickly. System threads are not very adapted to this. The number of kernel threads is limited (to few undreads) and any basic operation (creation destruction switching locking) is costly since it must be executed in kernel space.
The user threads on the other hand, can be implemented using set_jmp() and long_jmp() inside a user library. Since they don't involve the kernel an application can create/destroy and switch between user threads very efficiently.
As Ernest said, user threads are not very common any more, however there exists a hybrid solution that can take advantages of the two worlds.
http://en.wikipedia.org/wiki/Thread_(computer_science)#N:M_.28Hybrid_threading.29
Taking CPU affinity into account, will such an environment be useful with threading? Or will there be a performance degradation in such a system, if multiple users login and spawn multiple kernel and user threads?
When you say "taking CPU affinity into account" - are you saying that all processes have CPU affinity in this hypothetical system? Or is that just as one extra possible bit of information?
Using multiple threads will slow things down a bit if the system is already loaded (so there are more runnable threads than cores) but if there are often times where there are only (say) 2 users and 4 cores available, threading may help.
Another typical use for threads is to do something "in the background" whether that's explicitly using threads or using async calls. At that point multi-threading can definitely give a benefit (e.g. a non-hanging UI) without actually using more than one core simultaneously for much of the time.