mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Michael wang <wangyun@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Mike Galbraith <efault@gmx.de>,
	Alex Shi <alex.shi@linaro.org>, Paul Turner <pjt@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
Date: Thu, 15 May 2014 11:06:38 +0200	[thread overview]
Message-ID: <20140515090638.GI30445@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <53747EE4.3020605@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Thu, May 15, 2014 at 04:46:28PM +0800, Michael wang wrote:
> On 05/15/2014 04:35 PM, Peter Zijlstra wrote:
> > On Thu, May 15, 2014 at 11:46:06AM +0800, Michael wang wrote:
> >> But for the dbench, stress combination, that's not spin-wasted, dbench
> >> throughput do dropped, how could we explain that one?
> > 
> > I've no clue what dbench does.. At this point you'll have to
> > expose/trace the per-task runtime accounting for these tasks and ideally
> > also the things the cgroup code does with them to see if it still makes
> > sense.
> 
> I see :)
> 
> BTW, some interesting thing we found during the dbench/stress testing
> is, by doing:
> 
> 	echo 240000000 > /proc/sys/kernel/sched_latency_ns
>         echo NO_GENTLE_FAIR_SLEEPERS > /sys/kernel/debug/sched_features
> 
> that is sched_latency_ns increased around 10 times and
> GENTLE_FAIR_SLEEPERS was disabled, the dbench got it's CPU back.
> 
> However, when the group level is too deep, that doesn't works any more...
> 
> I'm not sure but seems like 'deep group level' and 'vruntime bonus for
> sleeper' is the keep points here, will try to list the root cause after
> more investigation, thanks for the hints and suggestions, really helpful ;-)

How deep is deep? You run into numerical problems quite quickly, esp.
when you've got lots of CPUs. We've only got 64bit to play with, that
said there were some patches...

What happens if you do the below, Google has been running with that, and
nobody was ever able to reproduce the report that got it disabled.



diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b2cbe81308af..e40819d39c69 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -40,7 +40,7 @@ extern void update_cpu_load_active(struct rq *this_rq);
  * when BITS_PER_LONG <= 32 are pretty high and the returns do not justify the
  * increased costs.
  */
-#if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage under light load  */
+#if 1 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage under light load  */
 # define SCHED_LOAD_RESOLUTION	10
 # define scale_load(w)		((w) << SCHED_LOAD_RESOLUTION)
 # define scale_load_down(w)	((w) >> SCHED_LOAD_RESOLUTION)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-05-15  9:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13  3:34 Michael wang
2014-05-13  9:47 ` Peter Zijlstra
2014-05-13 13:36   ` Rik van Riel
2014-05-13 14:23     ` Peter Zijlstra
2014-05-14  3:27       ` Michael wang
2014-05-14  7:36       ` Michael wang
2014-05-14  9:44         ` Peter Zijlstra
2014-05-15  3:46           ` Michael wang
2014-05-15  8:35             ` Peter Zijlstra
2014-05-15  8:46               ` Michael wang
2014-05-15  9:06                 ` Peter Zijlstra [this message]
2014-05-15  9:35                   ` Michael wang
2014-05-15 11:57                     ` Peter Zijlstra
2014-05-16  2:23                       ` Michael wang
2014-05-16  2:51                         ` Mike Galbraith
2014-05-16  4:24                           ` Michael wang
2014-05-16  7:54                             ` Peter Zijlstra
2014-05-16  8:15                               ` Michael wang
2014-06-10  8:56                               ` Michael wang
2014-06-10 12:12                                 ` Peter Zijlstra
2014-06-11  6:13                                   ` Michael wang
2014-06-11  8:24                                     ` Peter Zijlstra
2014-06-11  9:18                                       ` Michael wang
2014-06-23  9:42                                         ` Peter Zijlstra
2014-06-24  3:10                                           ` Michael wang
2014-05-16  7:48                         ` Peter Zijlstra
2014-05-14  3:21     ` Michael wang
2014-05-14  3:16   ` Michael wang

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=20140515090638.GI30445@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=alex.shi@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=wangyun@linux.vnet.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

Powered by JetHome