On Mon, 11 Jul, at 09:58:52AM, Dietmar Eggemann wrote:
> This difference in the initial se->avg.load_avg value [0 or 1024] has an
> influence in wake_affine() [weight = p->se.avg.load_avg;] for the wakeup
> handling of the hackbench tasks in the 'send/receive data' phase.
The way I was running ha
On 04/07/16 16:04, Matt Fleming wrote:
> On Wed, 15 Jun, at 04:32:58PM, Dietmar Eggemann wrote:
>> On 14/06/16 17:40, Mike Galbraith wrote:
>>> On Tue, 2016-06-14 at 15:14 +0100, Dietmar Eggemann wrote:
>>>
IMHO, the hackbench performance "boost" w/o 0905f04eb21f is due to the
fact that a
On Wed, 2016-07-06 at 12:45 +0100, Matt Fleming wrote:
> On Mon, 04 Jul, at 07:43:14PM, Mike Galbraith wrote:
> > On Mon, 2016-07-04 at 16:04 +0100, Matt Fleming wrote:
> >
> > > But we can optimise the special case of dequeueing the last entity and
> > > reset ::runnable_load_avg early, which giv
On Mon, 04 Jul, at 07:43:14PM, Mike Galbraith wrote:
> On Mon, 2016-07-04 at 16:04 +0100, Matt Fleming wrote:
>
> > But we can optimise the special case of dequeueing the last entity and
> > reset ::runnable_load_avg early, which gives a performance improvement
> > to workloads that trigger the lo
On Mon, 2016-07-04 at 16:04 +0100, Matt Fleming wrote:
> But we can optimise the special case of dequeueing the last entity and
> reset ::runnable_load_avg early, which gives a performance improvement
> to workloads that trigger the load balancer, such as fork-heavy
> applications when SD_BALANCE_
On Wed, 15 Jun, at 04:32:58PM, Dietmar Eggemann wrote:
> On 14/06/16 17:40, Mike Galbraith wrote:
> > On Tue, 2016-06-14 at 15:14 +0100, Dietmar Eggemann wrote:
> >
> >> IMHO, the hackbench performance "boost" w/o 0905f04eb21f is due to the
> >> fact that a new task gets all it's load decayed (mak
On 16/06/16 04:33, Mike Galbraith wrote:
> On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote:
>
>> Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT
>> machines on tip/sched/core? load.weight has a higher resolution than
>> runnable_load_avg (and so the values in the
On Wed, 2016-06-15 at 20:03 +0100, Dietmar Eggemann wrote:
> Isn't there a theoretical problem with the scale_load() on CONFIG_64BIT
> machines on tip/sched/core? load.weight has a higher resolution than
> runnable_load_avg (and so the values in the rq->cpu_load[] array).
> Theoretically because [
On 15/06/16 17:03, Mike Galbraith wrote:
> On Wed, 2016-06-15 at 16:32 +0100, Dietmar Eggemann wrote:
>
>>> In general, the fuzz helps us to not be so spastic. I'm not sure that
>>> we really really need to care all that much, because I strongly suspect
>>> that it's only gonna make any differenc
On Wed, 2016-06-15 at 16:32 +0100, Dietmar Eggemann wrote:
> > In general, the fuzz helps us to not be so spastic. I'm not sure that
> > we really really need to care all that much, because I strongly suspect
> > that it's only gonna make any difference at all in corner cases, but
> > there are r
On 14/06/16 17:40, Mike Galbraith wrote:
> On Tue, 2016-06-14 at 15:14 +0100, Dietmar Eggemann wrote:
>
>> IMHO, the hackbench performance "boost" w/o 0905f04eb21f is due to the
>> fact that a new task gets all it's load decayed (making it a small task)
>> in the __update_load_avg() call in remove
On Wed, 2016-06-15 at 06:42 +0800, Yuyang Du wrote:
> I am entirely for giving it a "clear unadulterated reality", and even
> more for it an option.
>
> Reviewed-by: Yuyang Du
Thanks. I'll have a look at perhaps having wake_affine to the same,
such that there is a clean separation of wake/LB p
On Tue, Jun 14, 2016 at 09:58:31AM +0200, Mike Galbraith wrote:
> SUSE's regression testing noticed that...
>
> 0905f04eb21f sched/fair: Fix new task's load avg removed from source CPU in
> wake_up_new_task()
>
> ...introduced a hackbench regression, and indeed it does. I think this
> regressio
On Tue, 2016-06-14 at 15:14 +0100, Dietmar Eggemann wrote:
> IMHO, the hackbench performance "boost" w/o 0905f04eb21f is due to the
> fact that a new task gets all it's load decayed (making it a small task)
> in the __update_load_avg() call in remove_entity_load_avg() because its
> se->avg.last_up
On 14/06/16 08:58, Mike Galbraith wrote:
> SUSE's regression testing noticed that...
>
> 0905f04eb21f sched/fair: Fix new task's load avg removed from source CPU in
> wake_up_new_task()
>
> ...introduced a hackbench regression, and indeed it does. I think this
> regression has more to do with r
SUSE's regression testing noticed that...
0905f04eb21f sched/fair: Fix new task's load avg removed from source CPU in
wake_up_new_task()
...introduced a hackbench regression, and indeed it does. I think this
regression has more to do with randomness than anything else, but in
general...
While
16 matches
Mail list logo
