1 | \chapter{Allocator} |
---|
2 | |
---|
3 | \noindent |
---|
4 | ==================== |
---|
5 | |
---|
6 | Writing Points: |
---|
7 | \begin{itemize} |
---|
8 | \item |
---|
9 | Objective of uHeapLmmm. |
---|
10 | \item |
---|
11 | Design philosophy. |
---|
12 | \item |
---|
13 | Background and previous design of uHeapLmmm. |
---|
14 | \item |
---|
15 | Distributed design of uHeapLmmm. |
---|
16 | |
---|
17 | ----- SHOULD WE GIVE IMPLEMENTATION DETAILS HERE? ----- |
---|
18 | |
---|
19 | \PAB{Maybe. There might be an Implementation chapter.} |
---|
20 | \item |
---|
21 | figure. |
---|
22 | \item |
---|
23 | Advantages of distributed design. |
---|
24 | \end{itemize} |
---|
25 | |
---|
26 | The new features added to uHeapLmmm (incl. @malloc_size@ routine) |
---|
27 | \CFA alloc interface with examples. |
---|
28 | \begin{itemize} |
---|
29 | \item |
---|
30 | Why did we need it? |
---|
31 | \item |
---|
32 | The added benefits. |
---|
33 | \end{itemize} |
---|
34 | |
---|
35 | |
---|
36 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
37 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
38 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% uHeapLmmm Design |
---|
39 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
40 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
41 | |
---|
42 | \section{Objective of uHeapLmmm} |
---|
43 | UHeapLmmm is a lightweight memory allocator. The objective behind uHeapLmmm is to design a minimal concurrent memory allocator that has new features and also fulfills GNU C Library requirements (FIX ME: cite requirements). |
---|
44 | |
---|
45 | \subsection{Design philosophy} |
---|
46 | |
---|
47 | |
---|
48 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
49 | |
---|
50 | \section{Background and previous design of uHeapLmmm} |
---|
51 | |
---|
52 | |
---|
53 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
54 | |
---|
55 | \section{Distributed design of uHeapLmmm} |
---|
56 | |
---|
57 | |
---|
58 | \subsection{Advantages of distributed design} |
---|
59 | |
---|
60 | |
---|
61 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
62 | |
---|
63 | \section{Added Features} |
---|
64 | |
---|
65 | |
---|
66 | \subsection{Methods} |
---|
67 | Why did we need it? |
---|
68 | The added benefits. |
---|
69 | |
---|
70 | |
---|
71 | \subsection{Alloc Interface} |
---|
72 | Why did we need it? |
---|
73 | The added benefits. |
---|
74 | |
---|
75 | |
---|
76 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
---|
77 | % Following is added by Peter |
---|
78 | |
---|
79 | \noindent |
---|
80 | ==================== |
---|
81 | |
---|
82 | \newpage |
---|
83 | \paragraph{Design 1: Decentralized} |
---|
84 | Fixed number of heaps: shard the heap into N heaps each with a bump-area allocated from the @sbrk@ area. |
---|
85 | Kernel threads (KT) are assigned to the N heaps. |
---|
86 | When KTs $\le$ N, the heaps are uncontented. |
---|
87 | When KTs $>$ N, the heaps are contented. |
---|
88 | By adjusting N, this approach reduces storage at the cost of speed due to contention. |
---|
89 | In all cases, a thread acquires/releases a lock, contented or uncontented. |
---|
90 | \begin{cquote} |
---|
91 | \centering |
---|
92 | \input{AllocDS1} |
---|
93 | \end{cquote} |
---|
94 | Problems: need to know when a KT is created and destroyed to know when to create/delete the KT's heap. |
---|
95 | On KT deletion, its heap freed-storage needs to be distributed somewhere. |
---|
96 | |
---|
97 | \paragraph{Design 2: Centralized} |
---|
98 | |
---|
99 | One heap, but lower bucket sizes are N-shared across KTs. |
---|
100 | This design leverages the fact that 95\% of allocation requests are less than 512 bytes and there are only 3--5 different request sizes. |
---|
101 | When KTs $\le$ N, the important bucket sizes are uncontented. |
---|
102 | When KTs $>$ N, the free buckets are contented. |
---|
103 | Therefore, threads are only contending for a small number of buckets, which are distributed among them to reduce contention. |
---|
104 | \begin{cquote} |
---|
105 | \centering |
---|
106 | \input{AllocDS2} |
---|
107 | \end{cquote} |
---|
108 | Problems: need to know when a kernel thread (KT) is created and destroyed to know when to assign a shared bucket-number. |
---|
109 | When no thread is assigned a bucket number, its free storage is unavailable. |
---|
110 | It is possible to use sharing and stealing techniques to share/find unused storage, when a free list is unused or empty. |
---|