public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael wang <wangyun@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>,
	Rik van Riel <riel@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	Alex Shi <alex.shi@linaro.org>, Paul Turner <pjt@google.com>,
	Mel Gorman <mgorman@suse.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance
Date: Tue, 24 Jun 2014 11:34:54 +0800	[thread overview]
Message-ID: <53A8F1DE.2060908@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140623094251.GS19860@laptop.programming.kicks-ass.net>

On 06/23/2014 05:42 PM, Peter Zijlstra wrote:
[snip]
>> +}
> 
> Still completely hate this, it doesn't make sense conceptual sense what
> so ever.

Yeah... and now I agree your opinion that this could not address all the
cases after all the testing these days...

Just wondering could we make this another scheduler feature?

I mean by logical, this will make tasks spread on each CPU inside
task-group, meanwhile follow the load-balance decision, the testing show
that the patch achieved that goal well.

Currently the scheduler haven't provide a good way to achieve that, correct?

And it do help a lot in our testing for workload like dbench and
transaction workload when they are fighting with stress likely workload,
combined with GENTLE_FAIR_SLEEPERS, we could make the cpu-shares works
again, here is some real numbers of 'dbench 6 -t 60' in our testing:

Without the patch:

 Operation      Count    AvgLat    MaxLat
 ----------------------------------------
 NTCreateX    1281241     0.036    62.872
 Close         941274     0.002    13.298
 Rename         54249     0.120    19.340
 Unlink        258686     0.156    37.155
 Deltree           36     8.514    41.904
 Mkdir             18     0.003     0.003
 Qpathinfo    1161327     0.016    40.130
 Qfileinfo     203648     0.001     7.118
 Qfsinfo       212896     0.004    11.084
 Sfileinfo     104385     0.067    55.990
 Find          448958     0.033    23.150
 WriteX        639464     0.069    55.452
 ReadX        2008086     0.009    24.466
 LockX           4174     0.012    14.127
 UnlockX         4174     0.006     7.357
 Flush          89787     1.533    56.925

Throughput 666.318 MB/sec  6 clients  6 procs  max_latency=62.875 ms


With the patch applied:

 Operation      Count    AvgLat    MaxLat
 ----------------------------------------
 NTCreateX    2601876     0.025    52.339
 Close        1911248     0.001     0.133
 Rename        110195     0.080     6.739
 Unlink        525476     0.070    52.359
 Deltree           62     6.143    19.919
 Mkdir             31     0.003     0.003
 Qpathinfo    2358482     0.009    52.355
 Qfileinfo     413190     0.001     0.092
 Qfsinfo       432513     0.003     0.790
 Sfileinfo     211934     0.027    13.830
 Find          911874     0.021     5.969
 WriteX       1296646     0.038    52.348
 ReadX        4079453     0.006    52.247
 LockX           8476     0.003     0.050
 UnlockX         8476     0.001     0.045
 Flush         182342     0.536    55.953

Throughput 1360.74 MB/sec  6 clients  6 procs  max_latency=55.970 ms

And the share works normally, the CPU% resources was managed well again.

So could we provide a feature like:

	SCHED_FEAT(TG_INTERNAL_BALANCE, false)

I do believe there are more cases could benefit from it, for those who
don't want too many wake-affine and want group-tasks more balanced on
each CPU, scheduler could provide this as an option then, shall we?

Regards,
Michael Wang

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2014-06-24  3:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18  4:50 [PATCH] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance Michael wang
2014-06-23  9:42 ` Peter Zijlstra
2014-06-24  3:34   ` Michael wang [this message]
2014-07-01  8:20     ` Peter Zijlstra
2014-07-01  8:38       ` Michael wang
2014-07-01  8:56         ` Peter Zijlstra
2014-07-02  2:47           ` Michael wang
2014-07-02 12:49             ` Peter Zijlstra
2014-07-02 13:15               ` Peter Zijlstra
2014-07-03 16:29                 ` Nicolas Pitre
2014-07-03  2:09               ` Michael wang
2014-07-02 14:47         ` Rik van Riel
2014-07-03  2:16           ` Michael wang
2014-07-03  3:51           ` Mike Galbraith
2014-07-11 16:11             ` Rik van Riel
2014-07-14  1:29               ` Michael wang
2014-06-30  7:36 ` Michael wang
2014-06-30  8:06   ` Mike Galbraith
2014-06-30  8:47     ` Michael wang
2014-06-30  9:27       ` Mike Galbraith
2014-07-01  2:57         ` Michael wang
2014-07-01  5:41           ` Mike Galbraith
2014-07-01  6:10             ` 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=53A8F1DE.2060908@linux.vnet.ibm.com \
    --to=wangyun@linux.vnet.ibm.com \
    --cc=alex.shi@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=umgwanakikbuti@gmail.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