sched: care and feeding of load-avg code (Re: [PATCH] sched: Foldingnohz load accounting more accurate)
From: Jonathan Nieder
Date: Fri Jul 20 2012 - 15:24:34 EST
Doug Smythies wrote:
> On my computer, and from a different thread from yesterday, I let
> the proposed "wang" patch multiple processes test continue for
> another 24 hours. The png file showing the results is attached, also
> available at .
Now that a nice patch seems to be available that takes care of
everything :), it seems like a good moment to make sure that the next
time there are scheduler changes people can easily see what they need
That is, what information would someone new to this code benefit from
in order to keep it working well?
I am particularly interested in making sure your tests don't get lost.
How about something like this?
-- >8 --
Subject: sched: add skeleton load-avg documentation
For now this is just a link to
http://www.smythies.com/~doug/network/load_average/ which has some
useful examples of how to test changes.
Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
Documentation/scheduler/00-INDEX | 2 ++
Documentation/scheduler/sched-load.txt | 16 ++++++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 Documentation/scheduler/sched-load.txt
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index d2651c47ae27..99c75547282d 100644
@@ -6,6 +6,8 @@ sched-design-CFS.txt
- goals, design and implementation of the Completely Fair Scheduler.
- information on scheduling domains.
+ - how load-average code works and how to keep it working.
- How and why the scheduler's nice levels are implemented.
diff --git a/Documentation/scheduler/sched-load.txt b/Documentation/scheduler/sched-load.txt
new file mode 100644
@@ -0,0 +1,16 @@
+Reported load averages are by necessity an approximation, but with
+care we can make sure they approximate reality most of the time.
+Talk about kernel/sched/core.c, including:
+* what is the expected load average?
+* workloads to test, automated testing
+* known problems, e.g. limitations due to finite-precision math
+* interaction with CPU frequency scaling
+* relevant links such as
+(Peter Zijlstra, Doug Smythies, Charles Wang)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/