Rev 9 | Rev 15 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed
| Rev | Author | Line No. | Line |
|---|---|---|---|
| 9 | bondari | 1 | <?xml version="1.0" encoding="UTF-8"?> |
| 11 | bondari | 2 | <chapter id="mm"> |
| 3 | <?dbhtml filename="mm.html"?> |
||
| 9 | bondari | 4 | |
| 11 | bondari | 5 | <title>Memory management</title> |
| 9 | bondari | 6 | |
| 11 | bondari | 7 | <section> |
| 8 | <title>Virtual memory management</title> |
||
| 9 | bondari | 9 | |
| 10 | <section> |
||
| 11 | bondari | 11 | <title>Address spaces</title> |
| 9 | bondari | 12 | |
| 13 | <para></para> |
||
| 14 | </section> |
||
| 15 | |||
| 16 | <section> |
||
| 11 | bondari | 17 | <title>Virtual address translation</title> |
| 9 | bondari | 18 | |
| 19 | <para></para> |
||
| 20 | </section> |
||
| 11 | bondari | 21 | </section> |
| 9 | bondari | 22 | |
| 11 | bondari | 23 | <section> |
| 24 | <title>Physical memory management</title> |
||
| 9 | bondari | 25 | |
| 11 | bondari | 26 | <section id="zones_and_frames"> |
| 27 | <title>Zones and frames</title> |
||
| 9 | bondari | 28 | |
| 11 | bondari | 29 | <para>Physical memory is divided into zones. Each zone represents |
| 30 | continuous area of physical memory frames. Allocation of frames is |
||
| 31 | handled by the <link linkend="buddy_allocator">buddy allocator</link> |
||
| 32 | associated with the zone. Zone also contains information about free and |
||
| 33 | occupied frames and its base addresss in the memory. Some of the |
||
| 34 | architectures (Mips, PPC) have only one zone, that covers whole physical |
||
| 35 | memory. Other architectures (IA32) have multiple zones.</para> |
||
| 36 | </section> |
||
| 9 | bondari | 37 | |
| 11 | bondari | 38 | <section id="buddy_allocator"> |
| 39 | <title>Buddy allocator</title> |
||
| 9 | bondari | 40 | |
| 11 | bondari | 41 | <para>Physical memory allocation inside one <link |
| 42 | linkend="zones_and_frames">memory zone</link> is being handled by buddy |
||
| 43 | allocation system. This approach greatly reduces possibility of memory |
||
| 44 | fragmentation and helps in allocating bigger continious blocks of |
||
| 45 | physical memory aligned to their size.</para> |
||
| 9 | bondari | 46 | |
| 11 | bondari | 47 | <graphic fileref="images/mm1.png" /> |
| 48 | |||
| 49 | <para>Frames are grouped into bigger blocks and blocks of the size i ^ 2 |
||
| 50 | are stored in the list indexed with <varname>i</varname> (so called |
||
| 51 | order index). If list contains 2 ajacent blocks (of a same size of |
||
| 52 | cause) they can be merged into the bigger one and moved into the list |
||
| 53 | with higher order index, thus making possible allocation of a bigger |
||
| 54 | block.</para> |
||
| 9 | bondari | 55 | </section> |
| 56 | |||
| 57 | <section> |
||
| 11 | bondari | 58 | <title>Slab allocator</title> |
| 9 | bondari | 59 | |
| 11 | bondari | 60 | <para>Kernel memory allocation is handled by slab.</para> |
| 9 | bondari | 61 | </section> |
| 11 | bondari | 62 | </section> |
| 9 | bondari | 63 | |
| 11 | bondari | 64 | <section> |
| 65 | <title>Memory sharing</title> |
||
| 9 | bondari | 66 | |
| 11 | bondari | 67 | <para>Not implemented yet(?)</para> |
| 68 | </section> |
||
| 69 | </chapter> |