From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rick Lindsley <ricklind@us.ibm.com>,
Ingo Molnar <mingo@redhat.com>, John Hawkes <hawkes@sgi.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Scheduler balancing statistics
Date: Fri, 02 Apr 2004 17:18:44 +1000 [thread overview]
Message-ID: <406D13D4.8040607@yahoo.com.au> (raw)
Hi,
I have been adapting Rick's schedstats package to extract
more information from the sched-domains infrastructure.
Before I release a patch, I'd like some input as to what
statistics people want covered, and in what form they would
like them presented (I'm talking only about balancing).
I have covered the basic stuff I could think of, and
written a small C program to parse it (I'm no good at perl)
and output this (sorry it is still pretty ugly):
npiggin@didi:~/usr/src/linux-2.4$ stats7 pre post
For domain0
31.005358l load balance calls / s move 1.162474l tasks / s
Of which, 66.198008l% calls and 67.187500l% task moves from idle balancing
93.539823l% found no imbalance
2.654867l% found an imbalance but failed
30.232558l% of tasks were moved with cache nice
Of which, 25.834798l% calls and 28.125000l% task moves from busy balancing
95.918367l% found no imbalance
0.000000l% found an imbalance but failed
100.000000l% of tasks were moved with cache nice
Of which, 7.967194l% calls and 4.687500l% task moves from newidle balancing
94.117647l% found no imbalance
0.000000l% found an imbalance but failed
100.000000l% of tasks were moved with cache nice
0.000000l active balances / s move 0.000000l tasks / s
0.036327l passive load balances / s
2.070657l affine wakeups / s
0.000000l exec balances / s
This was the behaviour during a make -j4 bzImage on a 2xSMP. For
a NUMA system, it would also give you domain1 for example.
A few interesting things this tells us: load_balance is being
called 31 times per second, ~95% of the time there is no imbalance,
and it moves 1.16 tasks per second.
idle balancing is going over the cache_nice_tries limit 70% of
the time which might warrant cache_nice_tries being increased.
etc.
Comments?
next reply other threads:[~2004-04-02 7:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-02 7:18 Nick Piggin [this message]
2004-04-02 7:35 ` Scheduler balancing statistics Rick Lindsley
2004-04-02 7:52 ` Nick Piggin
2004-04-02 8:53 ` Rick Lindsley
2004-04-02 9:59 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=406D13D4.8040607@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=hawkes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ricklind@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox