Rev 105 | Rev 133 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 105 | Rev 131 | ||
---|---|---|---|
Line 71... | Line 71... | ||
71 | <para>The last member of the context family is the memory management |
71 | <para>The last member of the context family is the memory management |
72 | context. It includes memory management registers that identify address |
72 | context. It includes memory management registers that identify address |
73 | spaces on hardware level (i.e. ASIDs and page tables pointers).</para> |
73 | spaces on hardware level (i.e. ASIDs and page tables pointers).</para> |
74 | 74 | ||
75 | <section> |
75 | <section> |
76 | <title>Synchronous context switches</title> |
76 | <title>Synchronous Context Switches</title> |
77 | 77 | ||
78 | <para>The scheduler, but also other pieces of the kernel, make heavy use |
78 | <para>The scheduler, but also other pieces of the kernel, make heavy use |
79 | of synchronous context switches, because it is a natural vehicle not |
79 | of synchronous context switches, because it is a natural vehicle not |
80 | only for changes in control flow, but also for switching between two |
80 | only for changes in control flow, but also for switching between two |
81 | kernel stacks. Two functions figure in a synchronous context switch |
81 | kernel stacks. Two functions figure in a synchronous context switch |
Line 120... | Line 120... | ||
120 | threads are visible to the scheduler and can become a subject of kernel |
120 | threads are visible to the scheduler and can become a subject of kernel |
121 | preemption and thread migration during times when preemption is |
121 | preemption and thread migration during times when preemption is |
122 | possible.</para> |
122 | possible.</para> |
123 | 123 | ||
124 | <formalpara> |
124 | <formalpara> |
125 | <title>Thread states</title> |
125 | <title>Thread States</title> |
126 | 126 | ||
127 | <para>In each moment, a thread exists in one of six possible thread |
127 | <para>In each moment, a thread exists in one of six possible thread |
128 | states. When the thread is created and first readied into the |
128 | states. When the thread is created and first readied into the |
129 | scheduler's run queues or when a thread is migrated to a new processor, |
129 | scheduler's run queues or when a thread is migrated to a new processor, |
130 | it is put into the <constant>Entering</constant> state. After some time, |
130 | it is put into the <constant>Entering</constant> state. After some time, |
Line 144... | Line 144... | ||
144 | state is not reached.<figure float="1"> |
144 | state is not reached.<figure float="1"> |
145 | <title>Transitions among thread states.</title> |
145 | <title>Transitions among thread states.</title> |
146 | 146 | ||
147 | <mediaobject id="thread_states" xreflabel=""> |
147 | <mediaobject id="thread_states" xreflabel=""> |
148 | <imageobject role="pdf"> |
148 | <imageobject role="pdf"> |
149 | <imagedata fileref="images/thread_states.pdf" |
149 | <imagedata fileref="images/thread_states.pdf" format="PDF" /> |
150 | format="PDF" /> |
- | |
151 | </imageobject> |
150 | </imageobject> |
152 | 151 | ||
153 | <imageobject role="html"> |
152 | <imageobject role="html"> |
154 | <imagedata fileref="images/thread_states.png" format="PNG" /> |
153 | <imagedata fileref="images/thread_states.png" format="PNG" /> |
155 | </imageobject> |
154 | </imageobject> |
156 | 155 | ||
157 | <imageobject role="fop"> |
156 | <imageobject role="fop"> |
158 | <imagedata fileref="images/thread_states.svg" |
157 | <imagedata fileref="images/thread_states.svg" format="SVG" /> |
159 | format="SVG" /> |
- | |
160 | </imageobject> |
158 | </imageobject> |
161 | </mediaobject> |
159 | </mediaobject> |
162 | </figure></para> |
160 | </figure></para> |
163 | </formalpara> |
161 | </formalpara> |
164 | 162 | ||
165 | <formalpara> |
163 | <formalpara> |
166 | <title>Pseudo threads</title> |
164 | <title>Pseudo Threads</title> |
167 | 165 | ||
168 | <para>HelenOS userspace layer knows even smaller units of execution. |
166 | <para>HelenOS userspace layer knows even smaller units of execution. |
169 | Each userspace thread can make use of an arbitrary number of pseudo |
167 | Each userspace thread can make use of an arbitrary number of pseudo |
170 | threads. These pseudo threads have their own synchronous register |
168 | threads. These pseudo threads have their own synchronous register |
171 | context, userspace code and stack. They live their own life within the |
169 | context, userspace code and stack. They live their own life within the |
Line 192... | Line 190... | ||
192 | 190 | ||
193 | <section> |
191 | <section> |
194 | <title>Scheduler</title> |
192 | <title>Scheduler</title> |
195 | 193 | ||
196 | <section> |
194 | <section> |
197 | <title>Run queues</title> |
195 | <title>Run Queues</title> |
198 | 196 | ||
199 | <para>There is an array of several run queues on each processor. The |
197 | <para>There is an array of several run queues on each processor. The |
200 | current version of HelenOS uses 16 run queues implemented by 16 doubly |
198 | current version of HelenOS uses 16 run queues implemented by 16 doubly |
201 | linked lists. Each of the run queues is associated with thread priority. |
199 | linked lists. Each of the run queues is associated with thread priority. |
202 | The lower the run queue index in the array is, the higher is the |
200 | The lower the run queue index in the array is, the higher is the |
Line 204... | Line 202... | ||
204 | in which those threads will execute. When kernel code wants to access |
202 | in which those threads will execute. When kernel code wants to access |
205 | the run queue, it must first acquire its lock.</para> |
203 | the run queue, it must first acquire its lock.</para> |
206 | </section> |
204 | </section> |
207 | 205 | ||
208 | <section> |
206 | <section> |
209 | <title>Scheduler operation</title> |
207 | <title>Scheduler Operation</title> |
210 | 208 | ||
211 | <para>The scheduler is invoked either explicitly when a thread calls the |
209 | <para>The scheduler is invoked either explicitly when a thread calls the |
212 | <code>scheduler</code> function (e.g. goes to sleep or merely wants to |
210 | <code>scheduler</code> function (e.g. goes to sleep or merely wants to |
213 | relinquish the processor for a while) or implicitly on a periodic basis |
211 | relinquish the processor for a while) or implicitly on a periodic basis |
214 | when the generic clock interrupt preempts the current thread. After its |
212 | when the generic clock interrupt preempts the current thread. After its |
Line 253... | Line 251... | ||
253 | point priority increase. In other words, the scheduler will now and then |
251 | point priority increase. In other words, the scheduler will now and then |
254 | move the entire run queues one level up.</para> |
252 | move the entire run queues one level up.</para> |
255 | </section> |
253 | </section> |
256 | 254 | ||
257 | <section> |
255 | <section> |
258 | <title>Processor load balancing</title> |
256 | <title>Processor Load Balancing</title> |
259 | 257 | ||
260 | <para>Normally, for the sake of cache locality, threads are scheduled on |
258 | <para>Normally, for the sake of cache locality, threads are scheduled on |
261 | one of the processors and don't leave it. Nevertheless, a situation in |
259 | one of the processors and don't leave it. Nevertheless, a situation in |
262 | which one processor is heavily overloaded while others sit idle can |
260 | which one processor is heavily overloaded while others sit idle can |
263 | occur. HelenOS deploys special kernel threads to help mitigate this |
261 | occur. HelenOS deploys special kernel threads to help mitigate this |