You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
812 lines
27 KiB
812 lines
27 KiB
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<meta name="generator" content="Asciidoctor 2.0.12">
|
|
<meta name="description" content="Life cycle of a process">
|
|
<meta name="keywords" content="ps aux">
|
|
<meta name="author" content="Apostolos rootApostolos@swarmlab.io">
|
|
<title>Linux process management !</title>
|
|
<link rel="stylesheet" href="http://cdnjs.cloudflare.com/ajax/libs/asciidoctor.js/1.5.9/css/asciidoctor.min.css">
|
|
<link rel="stylesheet" href="http://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.14.0/css/all.min.css">
|
|
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.18.3/styles/github.min.css">
|
|
</head>
|
|
<body class="article toc2 toc-right">
|
|
<div id="header">
|
|
<h1>Linux process management !</h1>
|
|
<div class="details">
|
|
<span id="author" class="author">Apostolos rootApostolos@swarmlab.io</span><br>
|
|
</div>
|
|
<div id="toc" class="toc2">
|
|
<div id="toctitle">Table of contents</div>
|
|
<ul class="sectlevel1">
|
|
<li><a href="#_life_cycle_of_a_process">1. Life cycle of a process</a>
|
|
<ul class="sectlevel2">
|
|
<li><a href="#_copy_on_write">1.1. copy-on-write</a></li>
|
|
<li><a href="#_zombie_processes">1.2. Zombie processes</a></li>
|
|
<li><a href="#_wait">1.3. wait</a></li>
|
|
<li><a href="#_orphan_process">1.4. Orphan process</a></li>
|
|
<li><a href="#_process_states">1.5. Process States</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#_thread">2. Thread</a>
|
|
<ul class="sectlevel2">
|
|
<li><a href="#_implementations">2.1. Implementations</a></li>
|
|
<li><a href="#_threads_vs_processes_pros_and_cons">2.2. Threads vs. processes pros and cons</a>
|
|
<ul class="sectlevel3">
|
|
<li><a href="#_when_should_you_prefer_fork_over_threading_and_vice_verse">2.2.1. When should you prefer fork() over threading and vice-verse?</a></li>
|
|
<li><a href="#_if_i_want_to_call_an_external_application_as_a_child_then_should_i_use_fork_or_threads_to_do_it">2.2.2. If I want to call an external application as a child, then should I use fork() or threads to do it?</a></li>
|
|
<li><a href="#_it_is_bad_thing_to_call_a_fork_inside_a_thread">2.2.3. it is bad thing to call a fork() inside a thread?</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#_process_memory">3. Process Memory</a></li>
|
|
<li><a href="#_process_priority_nice">4. Process priority (nice)</a></li>
|
|
<li><a href="#_scheduler">5. Scheduler</a></li>
|
|
<li><a href="#_context_switching">6. Context switching</a></li>
|
|
<li><a href="#_interrupts">7. Interrupts</a></li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div id="content">
|
|
<div id="preamble">
|
|
<div class="sectionbody">
|
|
<div class="sidebarblock">
|
|
<div class="content">
|
|
<div class="title">Life cycle of a process</div>
|
|
<div class="openblock float-group">
|
|
<div class="content">
|
|
<div class="imageblock related thumb right">
|
|
<div class="content">
|
|
<img src="./fork-exec-exit-wait.png" alt="350" width="350">
|
|
</div>
|
|
<div class="title">Figure 1. fork-exec <sup class="footnote">[<a id="_footnoteref_1" class="footnote" href="#_footnotedef_1" title="View footnote.">1</a>]</sup></div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p><strong>fork()</strong> is the the system call that the parent process uses to "divide" itself ("fork") into two identical processes.</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>After calling fork(), the created child process is an exact copy of the parent except for the return value of the fork() call.</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>This includes open files, register state, and all memory allocations, which includes the program’s executable code. In some cases the two continue to run the same binary,</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>the child switches to running another binary executable using the <strong>exec()</strong> system call.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_life_cycle_of_a_process">1. Life cycle of a process</h2>
|
|
<div class="sectionbody">
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>When a process forks, a complete copy of the executing program is made into the new process.</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>This new process is a child of the parent process, and has a new process identifier (PID).</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>The fork() function returns the child’s PID to the parent process.</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>The fork() function returns 0 to the child process.</p>
|
|
</li>
|
|
<li>
|
|
<p>This enables the two identical processes to distinguish one another.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>The parent process can either continue execution or wait for the child process to complete.</p>
|
|
</li>
|
|
<li>
|
|
<p>The child, after discovering that it is the child, replaces itself completely with another program, so that the code and address space of the original program are lost.</p>
|
|
</li>
|
|
<li>
|
|
<p>If the parent chooses to wait for the child to die, then the parent will receive the exit code of the program that the child executed.</p>
|
|
</li>
|
|
<li>
|
|
<p>To prevent the child becoming a zombie the parent should call wait on its children, either periodically or upon receiving the SIGCHLD signal, which indicates a child process has terminated.</p>
|
|
</li>
|
|
<li>
|
|
<p>One can also asynchronously wait on their children to finish, by using a signal handler for SIGCHLD, if they need to ensure everything is cleaned up.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="admonitionblock note">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-note" title="Note"></i>
|
|
</td>
|
|
<td class="content">
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>When the child process calls exec(), all data in the original program is lost, and it is replaced with a running copy of the new program.</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>This is known as overlaying.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>Although all data are replaced, the file descriptors that were open in the parent are closed only if the program has explicitly marked them close-on-exec.</p>
|
|
</li>
|
|
<li>
|
|
<p>This allows for the common practice of the parent creating a pipe prior to calling fork() and using it to communicate with the executed program.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_copy_on_write">1.1. copy-on-write</h3>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre>All processes are sharing the same set of pages and each one gets its own private copy when it wants to modify a page.</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p><strong>In such cases, a technique called copy-on-write (COW) is used.</strong></p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>With this technique, when a fork occurs, the parent process’s pages are not copied for the child process.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Instead, the pages are shared between the child and the parent process.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Whenever a process (parent or child) modifies a page, a separate copy of that particular page alone is made for that process (parent or child) which performed the modification.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>This process will then use the newly copied page rather than the shared one in all future references.
|
|
The other process (the one which did not modify the shared page) continues to use the original copy of the page (which is now no longer shared). This technique is called copy-on-write since the page is copied when some process writes to it.</p>
|
|
</div>
|
|
<div class="admonitionblock note">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-note" title="Note"></i>
|
|
</td>
|
|
<td class="content">
|
|
<div class="paragraph">
|
|
<p><strong>copy-on-write</strong> is lazy copying, child process copy the page when try to write it.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>So basically, after a fork, almost child’s memory is shared with parent.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Before any of the processes made, every child process still have some private memory, modified from parent’s or new allocating.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>That means even without any action the forked child process has some private memory.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>We can verify it with</p>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">cat /proc/PID/smaps
|
|
or
|
|
pmap PID</code></pre>
|
|
</div>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div class="admonitionblock tip">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-tip" title="Tip"></i>
|
|
</td>
|
|
<td class="content">
|
|
<div class="paragraph">
|
|
<p>This operation avoids unnecessary overhead because copying an entire address space is a very slow and inefficient operation which uses a lot of processor time and resources.</p>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_zombie_processes">1.2. Zombie processes</h3>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre>A child process always first becomes a zombie before being removed from the resource table.</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>When a process ends via exit, all of the memory and resources associated with it are deallocated so they can be used by other processes.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The process’s entry in the process table remains.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The parent can read the child’s exit status by executing the wait system call, whereupon the zombie is removed.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent receives whenever a child has died.</p>
|
|
</div>
|
|
<div class="admonitionblock note">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-note" title="Note"></i>
|
|
</td>
|
|
<td class="content">
|
|
<div class="paragraph">
|
|
<p>In most cases, under normal system operation zombies are immediately waited on by their parent and then reaped by the system – processes that stay zombies for a long time are generally an error and cause a resource leak, but the only resource they occupy is the process table entry – process ID.</p>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">It is not possible to kill such a process with the kill command, because it is already considered dead.
|
|
You can kill the parent process and then the zombie disappears as well.
|
|
|
|
Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the "STAT" column</code></pre>
|
|
</div>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_wait">1.3. wait</h3>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre>The child process will not be completely removed until the parent process knows of the termination of its child process by the wait() system call.</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>A process (or task) may wait on another process to complete its execution.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The parent process issue a wait system call, which suspends the execution of the parent process while the child executes.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>When the child process terminates, it returns an exit status to the operating system, which is then returned to the waiting parent process.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The parent process then resumes execution.</p>
|
|
</div>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_orphan_process">1.4. Orphan process</h3>
|
|
<div class="paragraph">
|
|
<p>A child process whose parent process terminates before it does becomes an orphan process.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Such situations are typically handled with a special "root" (or "init") process, which is assigned as the new parent of a process when its parent process exits.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>This special process detects when an orphan process terminates and then retrieves its exit status, allowing the system to deallocate the terminated child process.</p>
|
|
</div>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_process_states">1.5. Process States</h3>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">ps aux</code></pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>In the <strong>STAT</strong> column, you’ll see:</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>R: running or runnable, it is just waiting for the CPU to process it</p>
|
|
</li>
|
|
<li>
|
|
<p>S: Interruptible sleep, waiting for an event to complete, such as input from the terminal</p>
|
|
</li>
|
|
<li>
|
|
<p>D: Uninterruptible sleep, processes that cannot be killed or interrupted with a signal, usually to make them go away you have to reboot or fix the issue</p>
|
|
</li>
|
|
<li>
|
|
<p>Z: Zombie, we discussed in a previous lesson that zombies are terminated processes that are waiting to have their statuses collected</p>
|
|
</li>
|
|
<li>
|
|
<p>T: Stopped, a process that has been suspended/stopped</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_thread">2. Thread</h2>
|
|
<div class="sectionbody">
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre>A thread is an execution unit that has its own program counter, a stack and a set of registers that reside in a process</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Multiple threads can exist within one process, executing concurrently and sharing resources such as memory, while different processes do not share these resources.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The threads of a process share its executable code and the values of its dynamically allocated variables and non-thread-local global variables at any given time.</p>
|
|
</div>
|
|
<div class="openblock float-group">
|
|
<div class="content">
|
|
<div class="imageblock related thumb right">
|
|
<div class="content">
|
|
<img src="./Multithreaded_process.png" alt="350" width="350">
|
|
</div>
|
|
<div class="title">Figure 2. A process with two threads <sup class="footnote">[<a id="_footnoteref_2" class="footnote" href="#_footnotedef_2" title="View footnote.">2</a>]</sup></div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Threads in the same process share:</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>Process instructions</p>
|
|
</li>
|
|
<li>
|
|
<p>open files, data</p>
|
|
</li>
|
|
<li>
|
|
<p>signals and signal handlers</p>
|
|
</li>
|
|
<li>
|
|
<p>current working directory</p>
|
|
</li>
|
|
<li>
|
|
<p>User and group id</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="admonitionblock note">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-note" title="Note"></i>
|
|
</td>
|
|
<td class="content">
|
|
A thread is also called Light Weight Process (LWP).
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_implementations">2.1. Implementations</h3>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>LinuxThreads</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>The default thread implementation since Linux kernel 2.0 (introduced in 1996)</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>Native POSIX Thread Library (NPTL)</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>NPTL has been part of Red Hat Enterprise Linux since version 3, and in the Linux kernel since version 2.6. It is now a fully integrated part of the GNU C Library.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>Next Generation POSIX Thread (NGPT)</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>A IBM developed version of POSIX thread library. The NGPT team collaborated closely with the NPTL team and combined the best features of both implementations into NPTL.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="sect2">
|
|
<h3 id="_threads_vs_processes_pros_and_cons">2.2. Threads vs. processes pros and cons</h3>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>processes are typically independent, while threads exist as subsets of a process</p>
|
|
</li>
|
|
<li>
|
|
<p>processes carry considerably more state information than threads, whereas multiple threads within a process share process state as well as memory and other resources</p>
|
|
</li>
|
|
<li>
|
|
<p>processes have separate address spaces, whereas threads share their address space</p>
|
|
</li>
|
|
<li>
|
|
<p>processes interact only through system-provided inter-process communication mechanisms</p>
|
|
</li>
|
|
<li>
|
|
<p>context switching between threads in the same process typically occurs faster than context switching between processes</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Advantages and disadvantages of threads vs processes include:</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p><strong>Lower resource consumption of threads</strong>: using threads, an application can operate using fewer resources than it would need when using multiple processes.</p>
|
|
</li>
|
|
<li>
|
|
<p><strong>Simplified sharing and communication of threads</strong>: unlike processes, which require a message passing or shared memory mechanism to perform inter-process communication (IPC), threads can communicate through data, code and files they already share.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="admonitionblock tip">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-tip" title="Tip"></i>
|
|
</td>
|
|
<td class="content">
|
|
<strong>Thread crashes a process</strong>: due to threads sharing the same address space, an illegal operation performed by a thread can crash the entire process; therefore, one misbehaving thread can disrupt the processing of all the other threads in the application.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div class="sect3">
|
|
<h4 id="_when_should_you_prefer_fork_over_threading_and_vice_verse">2.2.1. When should you prefer fork() over threading and vice-verse?</h4>
|
|
<div class="paragraph">
|
|
<p>When you’re doing a far more complex task than just instantiating a worker, or you want the implicit security sandboxing of separate processes.</p>
|
|
</div>
|
|
</div>
|
|
<div class="sect3">
|
|
<h4 id="_if_i_want_to_call_an_external_application_as_a_child_then_should_i_use_fork_or_threads_to_do_it">2.2.2. If I want to call an external application as a child, then should I use fork() or threads to do it?</h4>
|
|
<div class="paragraph">
|
|
<p>If the child will do an identical task to the parent, with identical code, use fork. For smaller subtasks use threads.</p>
|
|
</div>
|
|
</div>
|
|
<div class="sect3">
|
|
<h4 id="_it_is_bad_thing_to_call_a_fork_inside_a_thread">2.2.3. it is bad thing to call a fork() inside a thread?</h4>
|
|
<div class="paragraph">
|
|
<p>it’s computationally rather expensive to duplicate a process and a lot of subthreads.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_process_memory">3. Process Memory</h2>
|
|
<div class="sectionbody">
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre>A process uses its own memory area to perform work.</pre>
|
|
</div>
|
|
</div>
|
|
<div class="openblock float-group">
|
|
<div class="content">
|
|
<div class="imageblock related thumb right">
|
|
<div class="content">
|
|
<img src="./program_in_memory2.png" alt="350" width="350">
|
|
</div>
|
|
<div class="title">Figure 3. Process Memory <sup class="footnote">[<a id="_footnoteref_3" class="footnote" href="#_footnotedef_3" title="View footnote.">3</a>]</sup></div>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>Text Segment.</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>The Text segment (a.k.a the Instruction segment) contains the executable program code and constant data.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>Data Segment</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>Heap</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>Heap is the segment from which the memory is provided. (e.g. malloc())</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>BSS:</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>The area where zero-initialized data is stored. All the global variable which are not initialized in the program are stored in the BSS segment.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>Data:</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>The area where initialized data are stored.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>Stack Segment</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>The stack segment is used by the process for the storage of automatic identifier, register variables, and function call information.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="title">what process is attached to a shared memory segment?</div>
|
|
<div class="content">
|
|
<pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">You can use:
|
|
ipcs -mp to get the process ID
|
|
and
|
|
with the command grep [shared memory segment] /proc/*/maps</code></pre>
|
|
</div>
|
|
</div>
|
|
<div class="admonitionblock tip">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-tip" title="Tip"></i>
|
|
</td>
|
|
<td class="content">
|
|
<strong>ipcs</strong> shows information on the inter-process communication facilities for which the calling process has read access.
|
|
By default it shows information about all three resources: shared memory segments, message queues, and semaphore arrays.
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_process_priority_nice">4. Process priority (nice)</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph">
|
|
<p>In Linux we can set guidelines for the CPU to follow when it is looking at all the tasks it has to do.
|
|
These guidelines are called niceness or nice value.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The "niceness" scale goes from</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>-20 (highest priority value)</p>
|
|
</li>
|
|
<li>
|
|
<p>19 (lowest priority value)</p>
|
|
</li>
|
|
<li>
|
|
<p>default is 0</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>The nice priority is actually used for user programs.</p>
|
|
</div>
|
|
<div class="admonitionblock note">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-note" title="Note"></i>
|
|
</td>
|
|
<td class="content">
|
|
Priority is all about managing processor time
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">nice run a program with modified scheduling priority
|
|
chrt allows to set your scheduling policy as well as priority.</code></pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_scheduler">5. Scheduler</h2>
|
|
<div class="sectionbody">
|
|
<div class="openblock float-group">
|
|
<div class="content">
|
|
<div class="imageblock related thumb right">
|
|
<div class="content">
|
|
<img src="./Simplified_Structure_of_the_Linux_Kernel.png" alt="350" width="350">
|
|
</div>
|
|
<div class="title">Figure 4. Structure of the Linux kernel <sup class="footnote">[<a id="_footnoteref_4" class="footnote" href="#_footnotedef_4" title="View footnote.">4</a>]</sup></div>
|
|
</div>
|
|
<div class="literalblock">
|
|
<div class="content">
|
|
<pre>The scheduler is the Linux kernel part that decides which runnable process will be executed by the CPU next.</pre>
|
|
</div>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>It handles CPU resource allocation for executing processes, and aims to maximize overall CPU utilization while also maximizing interactive performance.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="admonitionblock note">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-note" title="Note"></i>
|
|
</td>
|
|
<td class="content">
|
|
<div class="paragraph">
|
|
<p>The scheduler makes it possible to execute multiple programs at the same time, thus sharing the CPU with users of varying needs.</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>Minimizing response time</p>
|
|
</li>
|
|
<li>
|
|
<p>Maximizing overall CPU utilization</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
<div class="admonitionblock tip">
|
|
<table>
|
|
<tr>
|
|
<td class="icon">
|
|
<i class="fa icon-tip" title="Tip"></i>
|
|
</td>
|
|
<td class="content">
|
|
Since Linux 2.6.23, the default scheduler is CFS, the "Completely Fair Scheduler". The
|
|
CFS scheduler replaced the earlier "O(1)" scheduler. <sup class="footnote">[<a id="_footnoteref_5" class="footnote" href="#_footnotedef_5" title="View footnote.">5</a>]</sup> <sup class="footnote">[<a id="_footnoteref_6" class="footnote" href="#_footnotedef_6" title="View footnote.">6</a>]</sup>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_context_switching">6. Context switching</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph">
|
|
<p><strong>Context switch</strong> is the process of storing the state of a process or thread, so that it can be restored and resume execution at a later point.
|
|
This allows multiple processes to share a single central processing unit (CPU), and is an essential feature of a multitasking operating system.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>In the Linux kernel, context switching involves</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>switching registers</p>
|
|
</li>
|
|
<li>
|
|
<p>stack pointer</p>
|
|
</li>
|
|
<li>
|
|
<p>program counter</p>
|
|
</li>
|
|
<li>
|
|
<p>flushing the translation lookaside buffer (TLB)</p>
|
|
</li>
|
|
<li>
|
|
<p>and loading the page table of the next process to run (unless the old process shares the memory with the new).</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sect1">
|
|
<h2 id="_interrupts">7. Interrupts</h2>
|
|
<div class="sectionbody">
|
|
<div class="paragraph">
|
|
<p>An interrupt is an event that alters the normal execution flow of a program and can be generated by hardware devices or even by the CPU itself.</p>
|
|
</div>
|
|
<div class="paragraph">
|
|
<p>Interrupts can be grouped into two categories based on the source of the interrupt:</p>
|
|
</div>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>synchronous, generated by executing an instruction</p>
|
|
</li>
|
|
<li>
|
|
<p>asynchronous, generated by an external event</p>
|
|
<div class="ulist">
|
|
<ul>
|
|
<li>
|
|
<p>For example a network card generates an interrupts to signal that a packet has arrived.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="listingblock">
|
|
<div class="content">
|
|
<pre class="highlightjs highlight"><code class="language-bash hljs" data-lang="bash">Information related to hard interrupts at /proc/interrupts</code></pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div id="footnotes">
|
|
<hr>
|
|
<div class="footnote" id="_footnotedef_1">
|
|
<a href="#_footnoteref_1">1</a>. <a href="http://www.it.uu.se/education/course/homepage/os/vt18/images/module-2/fork-exec-exit-wait.png" class="bare" target="_blank" rel="noopener">http://www.it.uu.se/education/course/homepage/os/vt18/images/module-2/fork-exec-exit-wait.png</a>
|
|
</div>
|
|
<div class="footnote" id="_footnotedef_2">
|
|
<a href="#_footnoteref_2">2</a>. <a href="https://commons.wikimedia.org/w/index.php?curid=2233446" class="bare" target="_blank" rel="noopener">https://commons.wikimedia.org/w/index.php?curid=2233446</a>
|
|
</div>
|
|
<div class="footnote" id="_footnotedef_3">
|
|
<a href="#_footnoteref_3">3</a>. <a href="https://gabrieletolomei.files.wordpress.com/2013/10/program_in_memory2.png?w=960" class="bare" target="_blank" rel="noopener">https://gabrieletolomei.files.wordpress.com/2013/10/program_in_memory2.png?w=960</a>
|
|
</div>
|
|
<div class="footnote" id="_footnotedef_4">
|
|
<a href="#_footnoteref_4">4</a>. By ScotXW - Own work, CC BY-SA 4.0, <a href="https://commons.wikimedia.org/w/index.php?curid=47075153" class="bare" target="_blank" rel="noopener">https://commons.wikimedia.org/w/index.php?curid=47075153</a>
|
|
</div>
|
|
<div class="footnote" id="_footnotedef_5">
|
|
<a href="#_footnoteref_5">5</a>. <a href="https://en.wikipedia.org/wiki/Completely_Fair_Scheduler" class="bare" target="_blank" rel="noopener">https://en.wikipedia.org/wiki/Completely_Fair_Scheduler</a>
|
|
</div>
|
|
<div class="footnote" id="_footnotedef_6">
|
|
<a href="#_footnoteref_6">6</a>. <a href="https://www.kernel.org/doc/html/latest/scheduler/index.html" class="bare" target="_blank" rel="noopener">https://www.kernel.org/doc/html/latest/scheduler/index.html</a>
|
|
</div>
|
|
</div>
|
|
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.18.3/highlight.min.js"></script>
|
|
<script>
|
|
if (!hljs.initHighlighting.called) {
|
|
hljs.initHighlighting.called = true
|
|
;[].slice.call(document.querySelectorAll('pre.highlight > code')).forEach(function (el) { hljs.highlightBlock(el) })
|
|
}
|
|
</script>
|
|
</body>
|
|
</html>
|