-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathlunaris.html
72 lines (60 loc) · 2.85 KB
/
lunaris.html
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
<html>
<head>
<title>Help the Lunaris project!</title>
<link rel="stylesheet" href="workshop.css" type="text/css" />
</head>
<body>
<div id="column">
<div id="main">
<div id="head">
<img src="logo-solo.png" id="logo" />
<h1>Help the Lunaris project!</h1>
</div>
<div class="indexlink">
(<a href="index.html"><< back to index</a>)
</div>
<h2>Background</h2>
The scheduler of the kernel has a feature called a load balancer. It
is used for load balancing on multicore systems. On such systems, each
core has a list of processes it is running (a runqueue). If a core is
(nearly) idle, it will try to steal processes from a busy core, such
that in the end all cores are equally busy.
<p>See Robert Love, "Linux Kernel Development".
<a href="http://www.informit.com/articles/article.aspx?p=101760">Read
chapter 3 about the scheduler online</a>. Especially the second page,
half way down, deals with the load balancer.
<h2>The Problem</h2>
Within the Lunaris project, we're using a kernel containing several
patches. Somewhere along the way, we managed to break the load
balancer: Processes tend to remain on the core on which they were
originally started, even if that core is very busy and the other cores
have nothing to do.
<h3>Reproducing the problem</h3>
The first step is to tell Qemu to simulate a multi-core system. To do
this, add the option <tt>-smp 4</tt> to the <tt>qemu</tt> command
line. Be sure to start qemu with
the <a href="lunaris-linux-2.6.29.6.tar.bz2">Lunaris kernel</a>,
otherwise you will not have much luck.
To observe the problem, log into the system using ssh, and start
the <tt>top</tt> command. Once top is running, press the <tt>1</tt>
key, to show how busy the individual cores are. You should see four of
them :-)
In a different terminal, ssh into the system again, and start a couple
of processes:
<ul>
<li><tt>cp /dev/zero /dev/null & cp /dev/zero /dev/null & cp /dev/zero /dev/null & cp /dev/zero /dev/null &</tt>
</ul>
If you now observe top, you should see that each of the <tt>cp</tt>
processes is taking 25% cpu. Of the four cores, one is 100% busy, the
others are idle.
If load balancing was working as designed, it should detect this
situation, and move the <tt>cp</tt> processes to different cores. The
end result would be that each of the <tt>cp</tt> processes is taking
100% cpu. All cores are fully loaded.
</div>
<address>
<a href="mailto:[email protected]">Kees-Jan Dijkzeul</a>
</address>
</div>
</body>
</html>