Rev 48 | Rev 50 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 48 | Rev 49 | ||
---|---|---|---|
Line 57... | Line 57... | ||
57 | ready for execution is put into one of the run queues, depending on its |
57 | ready for execution is put into one of the run queues, depending on its |
58 | priority and its current processor, from where it is eventually picked up |
58 | priority and its current processor, from where it is eventually picked up |
59 | by the scheduler. Special purpose kernel threads strive to keep processors |
59 | by the scheduler. Special purpose kernel threads strive to keep processors |
60 | balanced by thread migration. Threads are scheduled by the round robing |
60 | balanced by thread migration. Threads are scheduled by the round robing |
61 | scheduling policy with respect to multiple priority run queues.</para> |
61 | scheduling policy with respect to multiple priority run queues.</para> |
- | 62 | </section> |
|
- | 63 | ||
- | 64 | <section> |
|
- | 65 | <title>Memory management</title> |
|
- | 66 | ||
- | 67 | <para>Memory management is another large subsystem in HelenOS. It serves |
|
- | 68 | the kernel to satisfy its own memory allocation requests, provides |
|
- | 69 | translation between virtual and physical memory addresses and manages |
|
- | 70 | virtual address spaces of userspace tasks.</para> |
|
- | 71 | ||
- | 72 | <para>Kernel allocates memory from the slab allocator, which itself |
|
- | 73 | allocates memory from a buddy system based allocator of physical memory |
|
- | 74 | frames.</para> |
|
- | 75 | ||
- | 76 | <para>The virtual address translation layer currently supports two |
|
- | 77 | mechanisms for mapping virtual memory pages to physical memory frames |
|
- | 78 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
|
- | 79 | further extensible to other mechanisms.</para> |
|
- | 80 | ||
- | 81 | <para>Userspace tasks depend on support of address spaces provided by the |
|
- | 82 | kernel. Each address space is a set of mutually dijunctive address space |
|
- | 83 | areas that group pages of common attributes. An address space area is |
|
- | 84 | usually connected to, and backed by, an anonymous memory or an executable |
|
- | 85 | image of some program. Anonymous memory address space areas can be easily |
|
- | 86 | shared among address spaces.</para> |
|
- | 87 | </section> |
|
- | 88 | ||
- | 89 | <section> |
|
- | 90 | <title>IPC</title> |
|
- | 91 | ||
- | 92 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
|
- | 93 | put on its IPC (Inter-Process Communication<footnote> |
|
- | 94 | <para>The term Inter-Process Communication is slightly confusing |
|
- | 95 | because in HelenOS terminology there are tasks instead of processes. |
|
- | 96 | However, its abbreviation, IPC, is being publicly used as a standard |
|
- | 97 | name for similar facilities. This book will therefore use the term IPC |
|
- | 98 | to refer to communication among tasks.</para> |
|
- | 99 | </footnote>). Tasks communicate by passing very short messages to one |
|
- | 100 | another or by sending (i.e. sharing) address space areas when larger data |
|
- | 101 | is to be transfered.</para> |
|
62 | 102 | ||
- | 103 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
|
- | 104 | is pretty similar to well-known abstraction of message queues. A task can |
|
- | 105 | have multiple simultaneous simplex connections to several other tasks. A |
|
- | 106 | connection leads from one of the source task's phones to the destination |
|
- | 107 | task's answerbox. The phones are used as handles for making calls to other |
|
- | 108 | tasks. Calls can be synchronous or asynchronous and can be forwarded from |
|
63 | <para></para> |
109 | one task to another.</para> |
64 | </section> |
110 | </section> |
65 | </chapter> |
111 | </chapter> |
66 | 112 |