On 07/12/2014 12:11 AM, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
[snip]
>>
>> That's full wake balance.. if that was cheap,
>> select_idle_sibling() would not exist.
>
> Full wake balance iterates over all the groups in the system,
> select_idle_sibling only over one LLC domain.
On 07/12/2014 12:11 AM, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
[snip]
That's full wake balance.. if that was cheap,
select_idle_sibling() would not exist.
Full wake balance iterates over all the groups in the system,
select_idle_sibling only over one LLC domain.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 11:51 PM, Mike Galbraith wrote:
> On Wed, 2014-07-02 at 10:47 -0400, Rik van Riel wrote:
>> On 07/01/2014 04:38 AM, Michael wang wrote:
>>> On 07/01/2014 04:20 PM, Peter Zijlstra wrote: [snip]
>
> Just wondering could we make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/02/2014 11:51 PM, Mike Galbraith wrote:
On Wed, 2014-07-02 at 10:47 -0400, Rik van Riel wrote:
On 07/01/2014 04:38 AM, Michael wang wrote:
On 07/01/2014 04:20 PM, Peter Zijlstra wrote: [snip]
Just wondering could we make this another
On Wed, 2 Jul 2014, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 02:49:18PM +0200, Peter Zijlstra wrote:
> > Clearly I need to go take out all these things because people don't seem
> > to know this and SCHED_DEBUG isn't a big enough hint. Tedious.
>
> Maybe this would be enough clue?
>
>
On Wed, 2 Jul 2014, Peter Zijlstra wrote:
On Wed, Jul 02, 2014 at 02:49:18PM +0200, Peter Zijlstra wrote:
Clearly I need to go take out all these things because people don't seem
to know this and SCHED_DEBUG isn't a big enough hint. Tedious.
Maybe this would be enough clue?
diff --git
On Wed, 2014-07-02 at 10:47 -0400, Rik van Riel wrote:
> On 07/01/2014 04:38 AM, Michael wang wrote:
> > On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
> > [snip]
> >>>
> >>> Just wondering could we make this another scheduler feature?
> >>
> >> No; sched_feat() is for debugging, BIG CLUE: its
On 07/02/2014 10:47 PM, Rik van Riel wrote:
> On 07/01/2014 04:38 AM, Michael wang wrote:
>> On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
>> [snip]
Just wondering could we make this another scheduler feature?
>>>
>>> No; sched_feat() is for debugging, BIG CLUE: its guarded by
>>>
On 07/02/2014 08:49 PM, Peter Zijlstra wrote:
> On Wed, Jul 02, 2014 at 10:47:34AM +0800, Michael wang wrote:
>> The opinion on features actually make me a little confusing... I used to
>> think the scheduler is willing on providing kinds of way to adapt itself
>> to different situation, and some
On 07/01/2014 04:38 AM, Michael wang wrote:
> On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
> [snip]
>>>
>>> Just wondering could we make this another scheduler feature?
>>
>> No; sched_feat() is for debugging, BIG CLUE: its guarded by
>> CONFIG_SCHED_DEBUG, anybody using it in production or
On Wed, Jul 02, 2014 at 02:49:18PM +0200, Peter Zijlstra wrote:
> Clearly I need to go take out all these things because people don't seem
> to know this and SCHED_DEBUG isn't a big enough hint. Tedious.
Maybe this would be enough clue?
---
include/linux/kernel.h | 1 +
On Wed, Jul 02, 2014 at 10:47:34AM +0800, Michael wang wrote:
> The opinion on features actually make me a little confusing... I used to
> think the scheduler is willing on providing kinds of way to adapt itself
> to different situation, and some features do help on that, make them
> only a debug
On Wed, Jul 02, 2014 at 10:47:34AM +0800, Michael wang wrote:
The opinion on features actually make me a little confusing... I used to
think the scheduler is willing on providing kinds of way to adapt itself
to different situation, and some features do help on that, make them
only a debug
On Wed, Jul 02, 2014 at 02:49:18PM +0200, Peter Zijlstra wrote:
Clearly I need to go take out all these things because people don't seem
to know this and SCHED_DEBUG isn't a big enough hint. Tedious.
Maybe this would be enough clue?
---
include/linux/kernel.h | 1 +
On 07/01/2014 04:38 AM, Michael wang wrote:
On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
[snip]
Just wondering could we make this another scheduler feature?
No; sched_feat() is for debugging, BIG CLUE: its guarded by
CONFIG_SCHED_DEBUG, anybody using it in production or anywhere else is
On 07/02/2014 08:49 PM, Peter Zijlstra wrote:
On Wed, Jul 02, 2014 at 10:47:34AM +0800, Michael wang wrote:
The opinion on features actually make me a little confusing... I used to
think the scheduler is willing on providing kinds of way to adapt itself
to different situation, and some
On 07/02/2014 10:47 PM, Rik van Riel wrote:
On 07/01/2014 04:38 AM, Michael wang wrote:
On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
[snip]
Just wondering could we make this another scheduler feature?
No; sched_feat() is for debugging, BIG CLUE: its guarded by
CONFIG_SCHED_DEBUG, anybody
On Wed, 2014-07-02 at 10:47 -0400, Rik van Riel wrote:
On 07/01/2014 04:38 AM, Michael wang wrote:
On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
[snip]
Just wondering could we make this another scheduler feature?
No; sched_feat() is for debugging, BIG CLUE: its guarded by
On 07/01/2014 04:56 PM, Peter Zijlstra wrote:
> On Tue, Jul 01, 2014 at 04:38:58PM +0800, Michael wang wrote:
[snip]
>> Currently when dbench running with stress, it could only gain one CPU,
>> and cpu-cgroup cpu.shares is meaningless, is there any good methods to
>> address that?
>
> So as far
On Tue, Jul 01, 2014 at 04:38:58PM +0800, Michael wang wrote:
> On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
> [snip]
> >>
> >> Just wondering could we make this another scheduler feature?
> >
> > No; sched_feat() is for debugging, BIG CLUE: its guarded by
> > CONFIG_SCHED_DEBUG, anybody using
On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
[snip]
>>
>> Just wondering could we make this another scheduler feature?
>
> No; sched_feat() is for debugging, BIG CLUE: its guarded by
> CONFIG_SCHED_DEBUG, anybody using it in production or anywhere else is
> broken.
>
> If people are using it, I
On Tue, Jun 24, 2014 at 11:34:54AM +0800, Michael wang wrote:
> 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
On 07/01/2014 01:41 PM, Mike Galbraith wrote:
> On Tue, 2014-07-01 at 10:57 +0800, Michael wang wrote:
>
>> IMHO, currently the generic scheduler just try to take care both latency
>> and throughput, both will take a little damage but won't be damaged too
>> much, they just sacrificed for each
On 07/01/2014 01:41 PM, Mike Galbraith wrote:
On Tue, 2014-07-01 at 10:57 +0800, Michael wang wrote:
IMHO, currently the generic scheduler just try to take care both latency
and throughput, both will take a little damage but won't be damaged too
much, they just sacrificed for each other...
On Tue, Jun 24, 2014 at 11:34:54AM +0800, Michael wang wrote:
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
On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
[snip]
Just wondering could we make this another scheduler feature?
No; sched_feat() is for debugging, BIG CLUE: its guarded by
CONFIG_SCHED_DEBUG, anybody using it in production or anywhere else is
broken.
If people are using it, I should
On Tue, Jul 01, 2014 at 04:38:58PM +0800, Michael wang wrote:
On 07/01/2014 04:20 PM, Peter Zijlstra wrote:
[snip]
Just wondering could we make this another scheduler feature?
No; sched_feat() is for debugging, BIG CLUE: its guarded by
CONFIG_SCHED_DEBUG, anybody using it in
On 07/01/2014 04:56 PM, Peter Zijlstra wrote:
On Tue, Jul 01, 2014 at 04:38:58PM +0800, Michael wang wrote:
[snip]
Currently when dbench running with stress, it could only gain one CPU,
and cpu-cgroup cpu.shares is meaningless, is there any good methods to
address that?
So as far as I
On Tue, 2014-07-01 at 10:57 +0800, Michael wang wrote:
> IMHO, currently the generic scheduler just try to take care both latency
> and throughput, both will take a little damage but won't be damaged too
> much, they just sacrificed for each other...
The cost can be large, so it's worth an
On 06/30/2014 05:27 PM, Mike Galbraith wrote:
> On Mon, 2014-06-30 at 16:47 +0800, Michael wang wrote:
[snip]
>>> While you're getting rid of the concept of 'GENTLE_FAIR_SLEEPERS', don't
>>> forget to also get rid of the concept of 'over-scheduling' :)
>>
>> I'm new to this word... could you give
On Mon, 2014-06-30 at 16:47 +0800, Michael wang wrote:
> Hi, Mike :)
>
> On 06/30/2014 04:06 PM, Mike Galbraith wrote:
> > On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote:
> >> On 06/18/2014 12:50 PM, Michael wang wrote:
> >>> By testing we found that after put benchmark (dbench) in to
Hi, Mike :)
On 06/30/2014 04:06 PM, Mike Galbraith wrote:
> On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote:
>> On 06/18/2014 12:50 PM, Michael wang wrote:
>>> By testing we found that after put benchmark (dbench) in to deep cpu-group,
>>> tasks (dbench routines) start to gathered on one
On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote:
> On 06/18/2014 12:50 PM, Michael wang wrote:
> > By testing we found that after put benchmark (dbench) in to deep cpu-group,
> > tasks (dbench routines) start to gathered on one CPU, which lead to that the
> > benchmark could only get around
On 06/18/2014 12:50 PM, Michael wang wrote:
> By testing we found that after put benchmark (dbench) in to deep cpu-group,
> tasks (dbench routines) start to gathered on one CPU, which lead to that the
> benchmark could only get around 100% CPU whatever how big it's task-group's
> share is, here is
On 06/18/2014 12:50 PM, Michael wang wrote:
By testing we found that after put benchmark (dbench) in to deep cpu-group,
tasks (dbench routines) start to gathered on one CPU, which lead to that the
benchmark could only get around 100% CPU whatever how big it's task-group's
share is, here is the
On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote:
On 06/18/2014 12:50 PM, Michael wang wrote:
By testing we found that after put benchmark (dbench) in to deep cpu-group,
tasks (dbench routines) start to gathered on one CPU, which lead to that the
benchmark could only get around 100%
Hi, Mike :)
On 06/30/2014 04:06 PM, Mike Galbraith wrote:
On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote:
On 06/18/2014 12:50 PM, Michael wang wrote:
By testing we found that after put benchmark (dbench) in to deep cpu-group,
tasks (dbench routines) start to gathered on one CPU, which
On Mon, 2014-06-30 at 16:47 +0800, Michael wang wrote:
Hi, Mike :)
On 06/30/2014 04:06 PM, Mike Galbraith wrote:
On Mon, 2014-06-30 at 15:36 +0800, Michael wang wrote:
On 06/18/2014 12:50 PM, Michael wang wrote:
By testing we found that after put benchmark (dbench) in to deep
On 06/30/2014 05:27 PM, Mike Galbraith wrote:
On Mon, 2014-06-30 at 16:47 +0800, Michael wang wrote:
[snip]
While you're getting rid of the concept of 'GENTLE_FAIR_SLEEPERS', don't
forget to also get rid of the concept of 'over-scheduling' :)
I'm new to this word... could you give more
On Tue, 2014-07-01 at 10:57 +0800, Michael wang wrote:
IMHO, currently the generic scheduler just try to take care both latency
and throughput, both will take a little damage but won't be damaged too
much, they just sacrificed for each other...
The cost can be large, so it's worth an
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
On Wed, Jun 18, 2014 at 12:50:17PM +0800, Michael wang wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fea7d33..e1381cd 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4409,6 +4409,62 @@ find_idlest_cpu(struct sched_group *group, struct
> task_struct
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
On Wed, Jun 18, 2014 at 12:50:17PM +0800, Michael wang wrote:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..e1381cd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4409,6 +4409,62 @@ find_idlest_cpu(struct sched_group *group, struct
task_struct *p, int
By testing we found that after put benchmark (dbench) in to deep cpu-group,
tasks (dbench routines) start to gathered on one CPU, which lead to that the
benchmark could only get around 100% CPU whatever how big it's task-group's
share is, here is the link of the way to reproduce the issue:
By testing we found that after put benchmark (dbench) in to deep cpu-group,
tasks (dbench routines) start to gathered on one CPU, which lead to that the
benchmark could only get around 100% CPU whatever how big it's task-group's
share is, here is the link of the way to reproduce the issue:
46 matches
Mail list logo
