All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Tim Chen <tim.c.chen@linux.intel.com>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Alex Shi <alex.shi@linaro.org>, Andi Kleen <andi@firstfloor.org>,
	Michel Lespinasse <walken@google.com>,
	Peter Hurley <peter@hurleysoftware.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Paul E.McKenney" <paulmck@linux.vnet.ibm.com>,
	Jason Low <jason.low2@hp.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] sched: Fast idling of CPU when system is partially loaded
Date: Mon, 23 Jun 2014 15:22:28 -0400	[thread overview]
Message-ID: <53A87E74.5090702@redhat.com> (raw)
In-Reply-To: <1403551009.2970.613.camel@schen9-DESK>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/23/2014 03:16 PM, Tim Chen wrote:
> Thanks to the review from Jason, Andi and Peter. I've updated the
> code as Peter suggested with simplified logic.
> 
> When a system is lightly loaded (i.e. no more than 1 job per cpu), 
> attempt to pull job to a cpu before putting it to idle is
> unnecessary and can be skipped.  This patch adds an indicator so
> the scheduler can know when there's no more than 1 active job is on
> any CPU in the system to skip needless job pulls.
> 
> On a 4 socket machine with a request/response kind of workload
> from clients, we saw about 0.13 msec delay when we go through a
> full load balance to try pull job from all the other cpus.  While
> 0.1 msec was spent on processing the request and generating a
> response, the 0.13 msec load balance overhead was actually more
> than the actual work being done. This overhead can be skipped much
> of the time for lightly loaded systems.
> 
> With this patch, we tested with a netperf request/response workload
> that has the server busy with half the cpus in a 4 socket system.
> We found the patch eliminated 75% of the load balance attempts
> before idling a cpu.
> 
> The overhead of setting/clearing the indicator is low as we already
> gather the necessary info while we call add_nr_running and
> update_sd_lb_stats. We switch to full load balance load immediately
> if any cpu got more than one job on its run queue in
> add_nr_running.  We'll clear the indicator to avoid load balance
> when we detect no cpu's have more than one job when we scan the
> work queues in update_sg_lb_stats.  We are aggressive in turning on
> the load balance and opportunistic in skipping the load balance.
> 
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Acked-by:
> Jason Low <jason.low2@hp.com>

Acked-by: Rik van Riel <riel@redhat.com>


- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTqH50AAoJEM553pKExN6DYj4H/17YlyWg0QDoNrkNbhEi8SfD
I0BsklbbDIpcq9hKpwiJOCiQNeVLjMwhTniKOOXj1LgbtSsHYz7Scac/vt9sJRsy
PLJKoQt43lSv7Ff3mJFbUZG5u2RWoLs8TLuSFhPd39J8XupJX9jVe3GejBsp8lN4
Mpmo2DD6FvjvF2mpIP+CpEDFQZNeEZBb9UMvAJCjAU4JwdodwFkLRgxTWyOUSFpS
eOhDj99nRgyCz0LwLaVD2mfi29B/C5giIk70G+1II9BjTDGlFJC9X5FairZ3bM+K
6//BDq1baNnVu7pKKtQe8bLhNFQ1z1WNtgDr8L9c6dw9rLI+5AGjZb+KK5mMnG8=
=goKD
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-06-23 19:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 19:16 [PATCH v4] sched: Fast idling of CPU when system is partially loaded Tim Chen
2014-06-23 19:22 ` Rik van Riel [this message]
2014-06-24 16:15 ` Tim Chen
2014-06-24 20:36   ` Peter Zijlstra
2014-07-05 10:44 ` [tip:sched/core] sched/fair: Implement fast idling of CPUs when the " tip-bot for Tim Chen

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=53A87E74.5090702@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linaro.org \
    --cc=andi@firstfloor.org \
    --cc=davidlohr@hp.com \
    --cc=jason.low2@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peter@hurleysoftware.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=walken@google.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.