All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rick Lindsley <ricklind@us.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>, John Hawkes <hawkes@sgi.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Scheduler balancing statistics
Date: Fri, 02 Apr 2004 19:59:33 +1000	[thread overview]
Message-ID: <406D3985.5000008@yahoo.com.au> (raw)
In-Reply-To: <200404020853.i328rQ303262@owlet.beaverton.ibm.com>

Rick Lindsley wrote:
> 	From an analysis standpoint it would be nice to know which of
> 	the major features are being activated for a particular load.
> 	So imbalance-driven moves, power-driven moves, and the number of
> 	times each domain tried to balance and failed would all be useful.
> 	I think your output covered those.
> 
>     It doesn't get into the finer points of how the imbalance is derived,
>     but maybe it should...
> 
> It's ok to wait and see if those are useful before implementing them. I
> suspect they would be relatively easily added if they were needed.
> One reason there are 6 versions of scheduler statistics is that the
> information needed kept changing, both due to a better understanding of
> bottlenecks and due to changing code.
> 

Yep.

>     Well, every domain that is reported here will cover the entire system
>     because it simply takes the sum of statistics from all domains.
> 
> I would suggest creating an output format that gives you all this
> information (since we have it anyway) but I think it is quite reasonable
> for the program which *interprets* this information to summarize it.
> 

OK, yeah that is a fine idea.

> 	Would you say these would be in addition to the schedstats or
> 	would these replace them?
> 
>     It will replace some of them, I think.
> 
> That's my thought too.	I would suggest that we merge them into one patch.
> Much as I'd like to see my schedstats hit the mainline, I think it
> is prudent to separate the major architectural changes sched-domains
> introduces from statistics both related and unrelated to them --
> and having two statistics patches for the scheduler, even if they are
> complementary, makes it harder on Andrew and more confusing for users.
> 

No, I started with your sources, and the plan has always
been to merge my changes back to you where possible.

      reply	other threads:[~2004-04-02 10:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-02  7:18 Scheduler balancing statistics Nick Piggin
2004-04-02  7:35 ` Rick Lindsley
2004-04-02  7:52   ` Nick Piggin
2004-04-02  8:53     ` Rick Lindsley
2004-04-02  9:59       ` Nick Piggin [this message]

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=406D3985.5000008@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.