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/
>
next prev parent 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