mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>
To: "Peter Williams" <pwil3058@bigpond.net.au>
Cc: "Ingo Molnar" <mingo@elte.hu>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [patch] CFS scheduler, -v12
Date: Tue, 22 May 2007 13:52:51 +0200	[thread overview]
Message-ID: <b647ffbd0705220452n711a8d1dtdf4cad07a01c8b64@mail.gmail.com> (raw)
In-Reply-To: <46523081.6050007@bigpond.net.au>

On 22/05/07, Peter Williams <pwil3058@bigpond.net.au> wrote:
> > [...]
> > Hum.. I guess, a 0/4 scenario wouldn't fit well in this explanation..
>
> No, and I haven't seen one.

Well, I just took one of your calculated probabilities as something
you have really observed - (*) below.

"The probabilities for the 3 split possibilities for random allocation are:

       2/2 (the desired outcome) is 3/8 likely,
       1/3 is 4/8 likely, and
       0/4 is 1/8 likely.            <-------------------------- (*)
"

> The split that I see is 3/1 and neither CPU seems to be favoured with
> respect to getting the majority.  However, top, gkrellm and X seem to be
> always on the CPU with the single spinner.  The CPU% reported by top is
> approx. 33%, 33%, 33% and 100% for the spinners.

Yes. That said, idle_balance() is out of work in this case.

> If I renice the spinners to -10 (so that there load weights dominate the
> run queue load calculations) the problem goes away and the spinner to
> CPU allocation is 2/2 and top reports them all getting approx. 50% each.

I wonder what would happen if X gets reniced to -10 instead (and
spinners are at 0).. I guess, something I described in my previous
mail (and dubbed "unlikely cospiracy" :) could happen, i.e. 0/4 and
then idle_balance() comes into play..

ok, I see. You have probably achieved a similar effect with the
spinners being reniced to 10 (but here both "X" and "top" gain
additional "weight" wrt the load balancing).

> I'm playing with some jitter experiments at the moment.  The amount of
> jitter needs to be small (a few tenths of a second) as the
> synchronization (if it's happening) is happening at the seconds level as
> the intervals for top and gkrellm will be in the 1 to 5 second range (I
> guess -- I haven't checked) and the load balancing is every 60 seconds.

Hum.. the "every 60 seconds" part puzzles me quite a bit. Looking at
the run_rebalance_domain(), I'd say that it's normally overwritten by
the following code

               if (time_after(next_balance, sd->last_balance + interval))
                        next_balance = sd->last_balance + interval;

the "interval" seems to be *normally* shorter than "60*HZ" (according
to the default params in topology.h).. moreover, in case of the CFS

                if (interval > HZ*NR_CPUS/10)
                        interval = HZ*NR_CPUS/10;

so it can't be > 0.2 HZ in your case (== once in 200 ms at max with
HZ=1000).. am I missing something? TIA


>
> Peter

-- 
Best regards,
Dmitry Adamushko

  parent reply	other threads:[~2007-05-22 11:53 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-13 15:38 Ingo Molnar
2007-05-16  2:04 ` Peter Williams
2007-05-16  8:08   ` Ingo Molnar
2007-05-16 23:42     ` Peter Williams
     [not found]   ` <20070516063625.GA9058@elte.hu>
2007-05-17 23:45     ` Peter Williams
     [not found]       ` <20070518071325.GB28702@elte.hu>
2007-05-18 13:11         ` Peter Williams
2007-05-18 13:26           ` Peter Williams
2007-05-19 13:27           ` Dmitry Adamushko
2007-05-20  1:41             ` Peter Williams
2007-05-21  8:29             ` William Lee Irwin III
2007-05-21  8:57               ` Ingo Molnar
2007-05-21 12:08                 ` William Lee Irwin III
2007-05-22 16:48                 ` Chris Friesen
2007-05-22 20:15                   ` Ingo Molnar
2007-05-22 20:49                     ` Chris Friesen
2007-05-21 15:25           ` Dmitry Adamushko
2007-05-21 23:51             ` Peter Williams
2007-05-22  4:47               ` Peter Williams
2007-05-22 12:03                 ` Peter Williams
2007-05-24  7:43                   ` Peter Williams
2007-05-24 16:45                     ` Siddha, Suresh B
2007-05-24 23:23                       ` Peter Williams
2007-05-29 20:45                         ` Siddha, Suresh B
2007-05-29 23:54                           ` Peter Williams
2007-05-30  0:50                             ` Siddha, Suresh B
2007-05-30  2:18                               ` Peter Williams
2007-05-30  4:42                                 ` Siddha, Suresh B
2007-05-30  6:28                                   ` Peter Williams
2007-05-31  1:49                                   ` Peter Williams
2007-05-22 11:52               ` Dmitry Adamushko [this message]
2007-05-23  0:10                 ` Peter Williams
2007-05-18  0:18 ` Bill Huey
2007-05-18  1:01   ` Bill Huey
2007-05-18  4:13   ` William Lee Irwin III
2007-05-18  7:31   ` Ingo Molnar

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=b647ffbd0705220452n711a8d1dtdf4cad07a01c8b64@mail.gmail.com \
    --to=dmitry.adamushko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pwil3058@bigpond.net.au \
    /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

all inboxes | Powered by JetHome®