/
ch9_qs_assignments.txt
101 lines (84 loc) · 3.82 KB
/
ch9_qs_assignments.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
As we conclude, here is a list of questions for you to test your knowledge
regarding this chapter's material. You will find answers to selected
questions here:
https://github.com/PacktPublishing/Linux-Kernel-Programming_2E/tree/master/solutions_to_assgn
Chapter 9 : Questions and/or Assignments
1. A very useful feature: when creating a custom slab cache with the
kmem_cache_create() API, you can arrange for an allocated object
instance to __________ via a _______.
a. be auto-freed; destructor function passed as an argument
b. get re-cached on being freed; flags parameter passed to it
c. be initialized; constructor function passed as an argument
d. get its process context to go to sleep; flags parameter passed to it
2. Spot the bug(s) in the following pseudocode!
/* called in process context ... */
void *foo(void)
{
void *v;
struct mys *p = kmalloc(sizeof(struct mys), GFP_KERNEL);
if (!p)
return -ENOMEM;
// ... do some work ...
v = vmalloc(LARGE_AMT);
if (!v)
return -ENOMEM;
// all ok, do more work ...
// ...
// work done
return p;
}
Bug(s): ________
a. A memory leak: the memory pointed to by p isn’t freed when
the vmalloc() API fails, plus it is out of scope: cannot return the
automatic/local variable to the caller.
b. A memory leak: the memory pointed to by p isn’t freed when
the vmalloc() API fails.
c. Cannot use GFP_KERNEL in a process context plus a memory leak:
the memory pointed to by p isn’t freed when the vmalloc() API fails.
d. Cannot use vmalloc() in a process context plus a memory leak:
the memory pointed to by p isn’t freed when the vmalloc() API fails
3. If the processor's silicon memory unit is passed an address it cannot
translate, it invokes the OS's registered _______.
a. party animals
b. slab cache
c. OOM killer
d. page fault handler
4. Imagine that the following user space malloc() (made by a thread X) has
succeeded and that ptr is non-null:
ptr = malloc(getpagesize()*10); ...
From the kernel perspective though, there is no guarantee that the memory is
physically allocated right away – this is called demand paging. Physical
memory allocation will only happen on a page-by-page basis when thread X
______ any address within the page, thus causing a ______.
a. accesses (for r/w/x); segmentation fault
b. writes; page fault
c. accesses (for r/w/x); page fault
d. reads; page fault
5. Assignment : slab_custom_mult
Write a kernel module that creates multiple custom slab caches
(slab_custom_mult). Fix the total number of custom caches as, say, 100. Set
the name of the caches as our_slab-n; where n is an integer from 0 to 99.
The size of the object in each cache also varies; start with a fixed size, say,
300 bytes, and keep incrementing the size by a multiplier factor (say, 300
bytes). So, it looks like this:
Slab cache Name Size
our_slab-0 300
our_slab-2 600
our_slab-3 900
[...]
our_slab-98 29700
our_slab-99 30000
Also, why not make the multiplier size a module parameter, called xfactor.
After it's loaded, look up the kernel log and use vmstat(8) (or other
utilities) to see all your custom slab caches!
Do sudo vmstat -m |grep "^our_slab" to see how much memory is actually
allocated to each object in each custom slab cache (it's the fourth column,
as you earlier learned).
6. show_all_oom:
Write a script (or C program, it's up to you) to display the current OOM
score of all the processes alive on the system.
(Tip: https://dev.to/rrampage/surviving-the-linux-oom-killer-2ki9)
7. Read:
a) Per-file OOM badness, Jon Corbet, June 2022, LWN: https://lwn.net/Articles/896738/
b) oom_badness(): read about one instance on how this function was improved:
https://github.com/torvalds/linux/commit/9066e5cfb73cdbcdbb49e87999482ab615e9fc76