Hobbits give presents to other people on their own birthdays. Not very expensive ones, as a rule, but it was not a bad system. Actually in Hobbiton and Bywater every day in the year it was somebody's birthday, so that every hobbit in those parts had a fair chance of at least one present at least once a week.
—The Fellowship of the Ring, Book 1, Chapter 1
Linux's CFS strives to be completely fair, meaning that all processes should recieve an equal share of the processor time. In particular, if there are a total of N processes in the system, then all processes will ideally recieve exactly 1/Nth of the processor time. In this studio we will explore the CFS from user space.
In this studio, you will:
Please complete the required exercises below, as well as any optional enrichment exercises that you wish to complete.
As you work through these exercises, please record your answers, and when finished email your results to dferry@email.wustl.edu with the phrase CFS Studio in the subject line.
Make sure that the name of each person who worked on these exercises is listed in the first answer, and make sure you number each of your responses so it is easy to match your responses with each exercise.
/proc/sys/kernel/sched_autogroup_enabled from 1 to 0. You can
do this with the command echo 0 > sched_autogroup_enabled, but
you will probably have to have a root terminal (sudo bash) in
order to modify the value. If we did not do this, then the way that you
invoked the exercises in this studio would influence your results.
while(1) loop, but we want a little control over
where this task executes. To do this, we will use Linux's processor
affinities.
For this exercise, write a infinite-loop program that takes one integer argument
which gives the processor that the program should execute upon. In order to
control where your process is allowed to run you can use the function
sched_setaffinity(). To use this function you will need to specify
the set of allowable CPUs with a variable of type cpu_set_t. In
order to manipulate this data type you should use the functions documented in
man CPU_SET. This is a nonstandard extension, so you will need to
place #define _GNU_SOURCE before you include sched.h.
Verify that your program runs continuously on a processor of your choosing
with the top or trace-cmd commands.
Take a moment and marvel at the fact that your system hasn't come crashing to a halt. Do a few tasks of your own choosing (text editing, internet browsing, etc.) and make a subjective judgement of how well the system responds now versus before you started the infinite loop tasks.
As the answer to this question, describe your experience.
dense_mm program from previous studios
to examine the behavior of CPU-bound tasks on a heavily loaded system. First,
kill your background workload and
use the command time ./dense_mm 300 to get a rough measure of
program execution time on a quiet system. Now, restart the background tasks
and run the same command again.
As the answer to this exercise, copy and paste each response.
real and user timings.
What does the previous exercise tell you about the way that two
CPU-bound tasks share a processors under the CFS?
real and
user time of dense_mm 300 if you were to increase the
number of background tasks?
time ./dense_mm 300 and copy and
paste the results here. What happened?
Two helpful tips. You can detach a command from the terminal by executing it
with an ampersand (&) at the end. Also, you can kill all tasks matching a
a certain string with the pkill command. For example, if I named
my infinite loop task while, then I could create multiple tasks
on processor zero with the command ./while 0 &. When I was
done, I could kill all outstanding tasks with the command
pkill while.
nice priorities do influence the proportion of
time a task recieves.
Run the command time sudo nice -n -20 ./dense_mm 300. What
proportion of time (user divided by real)
did the task recieve?
CTRL-C. Compute their runtime proportions.