| 1,22 → 1,110 |
|---|
| <?xml version="1.0" encoding="UTF-8"?> |
| <chapter id="scheduling"> |
| <?dbhtml filename="scheduling.html"?> |
| |
| <chapter id="scheduling"><?dbhtml filename="scheduling.html"?> |
| <title>Scheduling</title> |
| <para> |
| One of the key tasks of the operating system is to create and support impression that several activities are running contemporarily in the system. This is true for both uniprocessor as well as multiprocessor systems. In the case of multiprocessor systems, the activities are trully running in parallel |
| </para> |
| |
| <title>Scheduling</title> |
| |
| <para>One of the key aims of the operating system is to create and support |
| the impression that several activities are executing contemporarily. This is |
| true for both uniprocessor as well as multiprocessor systems. In the case of |
| multiprocessor systems, the activities are trully happening in parallel. The |
| scheduler helps to materialize this impression by planning threads on as |
| many processors as possible and, where this means reaches its limits, by |
| quickly switching among threads executing on a single processor.</para> |
| |
| <section> |
| <title>Contexts</title> |
| |
| <para>The term context refers to the set of processor resources that |
| define the current state of the computation or the environment and the |
| kernel understands it in several more or less narrow sences:</para> |
| |
| <itemizedlist> |
| <listitem> |
| <para>synchronous register context,</para> |
| </listitem> |
| |
| <listitem> |
| <para>asynchronous register context,</para> |
| </listitem> |
| |
| <listitem> |
| <para>FPU context and</para> |
| </listitem> |
| |
| <listitem> |
| <para>memory management context.</para> |
| </listitem> |
| </itemizedlist> |
| |
| <para>The most narrow sence refers to the the synchronous register |
| context. It includes all the preserved registers as defined by the |
| architecture. To highlight some, the program counter and stack pointer |
| take part in the synchronous register context. These are the registers |
| that must be preserved across a procedure call and during synchronous |
| context switches. </para> |
| |
| <para>The next type of the context understood by the kernel is the |
| asynchronous register context. On an interrupt, the interrupted execution |
| flow's state must be guaranteed to be eventually completely restored. |
| Therefore the interrupt context includes, among other things, the scratch |
| registers as defined by the architecture. As a special optimization and if |
| certain conditions are met, it need not include the architecture's |
| preserved registers. The condition mentioned in the previous sentence is |
| that the low-level assembly language interrupt routines don't modify the |
| preserved registers. The handlers usually call a higher-level C routine. |
| The preserved registers are then saved on the stack by the compiler |
| generated code of the higher-level function. In HelenOS, several |
| architectures can be compiled with this optimization.</para> |
| |
| <para>Although the kernel does not do any floating point |
| arithmetics<footnote> |
| <para>Some architectures (e.g. ia64) inevitably use a fixed set of |
| floating point registers to carry out its normal operations.</para> |
| </footnote>, it must protect FPU context of userspace threads against |
| destruction by other threads. Moreover, only a fraction of userspace |
| programs use the floating point unit. HelenOS contains a generic framework |
| for switching FPU context only when the switch is forced.</para> |
| |
| <para>The last member of the context family is the memory management |
| context. It includes memory management registers that identify address |
| spaces on hardware level (i.e. ASIDs and page tables pointers).</para> |
| |
| <section> |
| <title>Context switching</title> |
| <title>Synchronous context switches</title> |
| |
| <para>Something about context. Probably arch specific context notes.</para> |
| <para>The scheduler, but also other pieces of the kernel, make heavy use |
| of synchronous context switches, because it is a natural vehicle not |
| only for changes in control flow, but also for switching between two |
| kernel stacks. Two functions figure in a synchronous context switch |
| implementation: <code>context_save</code> and |
| <code>context_restore</code>. Note that these two functions break the |
| natural perception of the linear C code execution flow starting at |
| function's entry point and ending on one of the function's exit |
| points.</para> |
| |
| <para>When the <code>context_save</code> function is called, the |
| synchronous context is saved in a memory structure passed to it. After |
| executing <code>context_save</code>, the caller is returned 1 as a |
| return value. The execution of instructions continues as normally until |
| <code>context_restore</code> is called. For the caller, it seems like |
| the call never returns<footnote> |
| <para>Which might be a source of problems with variable liveliness |
| after <code>context_restore</code>.</para> |
| </footnote>. Nevertheless, a synchronous register context, which is |
| saved in a memory structure passed to <code>context_restore,</code> is |
| restored, thus transfering the control flow to the place of occurrence |
| of the corresponding call to <code>context_save</code>. From the |
| perspective of the caller of the corresponding |
| <code>context_save</code>, it looks as though a return from |
| <code>context_save</code>. However, this time a return value of 0 is |
| returned.</para> |
| </section> |
| </section> |
| |
| <section> |
| <title>Scheduler</title> |
| <para>How scheduler designed and how it works.</para> |
| </section> |
| <section> |
| <title>Scheduler</title> |
| |
| |
| </chapter> |
| <para>How scheduler designed and how it works.</para> |
| </section> |
| </chapter> |