On 19 October 2016 at 11:53, Peter Zijlstra wrote:
> On Wed, Oct 19, 2016 at 08:38:12AM +0200, Vincent Guittot wrote:
>> > It might make sense to have helper functions to evaluate those
>>
>> The main issue is the number of parameters used in these conditions
>> that makes helper function not real
On Wed, Oct 19, 2016 at 08:38:12AM +0200, Vincent Guittot wrote:
> > It might make sense to have helper functions to evaluate those
>
> The main issue is the number of parameters used in these conditions
> that makes helper function not really more readable.
Fair enough I suppose..
> > condition
On 18 October 2016 at 14:15, Peter Zijlstra wrote:
> On Tue, Oct 18, 2016 at 12:29:57PM +0100, Matt Fleming wrote:
>> On Tue, 18 Oct, at 01:10:17PM, Peter Zijlstra wrote:
>> >
>> > I'm entirely lost as to which patch we're talking about by now ;-)
>>
>> Heh, this one from Vincent,
>>
>> https://
On 18 October 2016 at 13:09, Peter Zijlstra wrote:
> On Wed, Oct 12, 2016 at 09:41:36AM +0200, Vincent Guittot wrote:
>
>> ok. In fact, I have noticed another regression with tip/sched/core and
>> hackbench while looking at yours.
>> I have bisect to :
>> 10e2f1acd0 ("sched/core: Rewrite and impro
On Tue, Oct 18, 2016 at 12:29:57PM +0100, Matt Fleming wrote:
> On Tue, 18 Oct, at 01:10:17PM, Peter Zijlstra wrote:
> >
> > I'm entirely lost as to which patch we're talking about by now ;-)
>
> Heh, this one from Vincent,
>
> https://lkml.kernel.org/r/20161010173440.ga28...@linaro.org
Ah, r
On Tue, 18 Oct, at 01:10:17PM, Peter Zijlstra wrote:
>
> I'm entirely lost as to which patch we're talking about by now ;-)
Heh, this one from Vincent,
https://lkml.kernel.org/r/20161010173440.ga28...@linaro.org
On Tue, Oct 18, 2016 at 11:29:37AM +0100, Matt Fleming wrote:
> On Tue, 11 Oct, at 11:24:53AM, Matt Fleming wrote:
> >
> > That's a lot more costly cross-DIE migrations. I think this patch is
> > along the right lines, but there's something fishy happening on this
> > box.
>
> I wasn't really abl
On Wed, Oct 12, 2016 at 09:41:36AM +0200, Vincent Guittot wrote:
> ok. In fact, I have noticed another regression with tip/sched/core and
> hackbench while looking at yours.
> I have bisect to :
> 10e2f1acd0 ("sched/core: Rewrite and improve select_idle_siblings")
>
> hackbench -P -g 1
>
>
On Tue, 11 Oct, at 11:24:53AM, Matt Fleming wrote:
>
> That's a lot more costly cross-DIE migrations. I think this patch is
> along the right lines, but there's something fishy happening on this
> box.
I wasn't really able to track down why this machine regressed, and the
patch shows enough impro
On Tue, 11 Oct, at 11:39:57AM, Matt Fleming wrote:
> On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote:
> >
> > [...]
> >
> > Yeah, you're right. But I can't see any significant difference. IMHO,
> > it's all in the noise.
> >
> > (A) Performance counter stats for 'perf bench sched messaging
On 11 October 2016 at 20:57, Matt Fleming wrote:
> On Tue, 11 Oct, at 03:14:47PM, Vincent Guittot wrote:
>> >
>> > I see a regression,
>> >
>> > baseline: 2.41228
>> > patched : 2.64528 (-9.7%)
>>
>> Just to be sure; By baseline you mean v4.8 ?
>
> Baseline is actually tip/sched/core commit 44
On Tue, 11 Oct, at 03:14:47PM, Vincent Guittot wrote:
> >
> > I see a regression,
> >
> > baseline: 2.41228
> > patched : 2.64528 (-9.7%)
>
> Just to be sure; By baseline you mean v4.8 ?
Baseline is actually tip/sched/core commit 447976ef4fd0
("sched/irqtime: Consolidate irqtime flushing cod
On 11 October 2016 at 12:24, Matt Fleming wrote:
> On Mon, 10 Oct, at 07:34:40PM, Vincent Guittot wrote:
>>
>> Subject: [PATCH] sched: use load_avg for selecting idlest group
>>
>> select_busiest_group only compares the runnable_load_avg when looking for
>> the idlest group. But on fork intensive
On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote:
>
> [...]
>
> Yeah, you're right. But I can't see any significant difference. IMHO,
> it's all in the noise.
>
> (A) Performance counter stats for 'perf bench sched messaging -g 100 -l
> 1 -t'
> # 20 sender and receiver threads per g
On Mon, 10 Oct, at 06:09:14PM, Wanpeng Li wrote:
> 2016-10-10 18:01 GMT+08:00 Matt Fleming :
> > On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
> >>
> >> The difference between this patch and Peterz's is your patch have a
> >> delta since activate_task()->enqueue_task() does do update_rq_clock(),
On Mon, 10 Oct, at 07:34:40PM, Vincent Guittot wrote:
>
> Subject: [PATCH] sched: use load_avg for selecting idlest group
>
> select_busiest_group only compares the runnable_load_avg when looking for
> the idlest group. But on fork intensive use case like hackbenchw here task
> blocked quickly af
On 10/10/16 19:29, Vincent Guittot wrote:
> On 10 October 2016 at 15:54, Dietmar Eggemann
> wrote:
>> On 10/10/16 13:29, Vincent Guittot wrote:
>>> On 10 October 2016 at 12:01, Matt Fleming wrote:
On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
[...]
>>> I have tried to reprocude your is
On 10 October 2016 at 15:54, Dietmar Eggemann wrote:
> On 10/10/16 13:29, Vincent Guittot wrote:
>> On 10 October 2016 at 12:01, Matt Fleming wrote:
>>> On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
The difference between this patch and Peterz's is your patch have a
delta since
Le Monday 10 Oct 2016 à 14:29:28 (+0200), Vincent Guittot a écrit :
> On 10 October 2016 at 12:01, Matt Fleming wrote:
> > On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
> >>
> >> The difference between this patch and Peterz's is your patch have a
> >> delta since activate_task()->enqueue_task()
On 10/10/16 13:29, Vincent Guittot wrote:
> On 10 October 2016 at 12:01, Matt Fleming wrote:
>> On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
>>>
>>> The difference between this patch and Peterz's is your patch have a
>>> delta since activate_task()->enqueue_task() does do update_rq_clock(),
>>
On 10 October 2016 at 12:01, Matt Fleming wrote:
> On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
>>
>> The difference between this patch and Peterz's is your patch have a
>> delta since activate_task()->enqueue_task() does do update_rq_clock(),
>> so why don't have the delta will cause low cpu
2016-10-10 18:01 GMT+08:00 Matt Fleming :
> On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
>>
>> The difference between this patch and Peterz's is your patch have a
>> delta since activate_task()->enqueue_task() does do update_rq_clock(),
>> so why don't have the delta will cause low cpu machines
On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote:
>
> The difference between this patch and Peterz's is your patch have a
> delta since activate_task()->enqueue_task() does do update_rq_clock(),
> so why don't have the delta will cause low cpu machines (4 or 8) to
> regress against your another rep
2016-09-29 3:37 GMT+08:00 Matt Fleming :
> On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote:
>>
>> Which suggests we do something like the below (not compile tested or
>> anything, also I ran out of tea again).
>
> I'm away on FTO right now. I can test this when I return on Friday.
>
> Funnily e
On Wed, 28 Sep, at 05:00:20AM, Vincent Guittot wrote:
>
> Matt,
>
> May be you can try this patch which uses utilization in
> find_idlest_group. So even if runnable_load_avg is null, the
> utilization should not and another cpu will be chosen
> https://patchwork.kernel.org/patch/9306939/
Unfortu
On Wed, 28 Sep, at 04:46:06AM, Vincent Guittot wrote:
>
> ok so i'm a bit confused there
> my understand of your explanation above is that now we left a small
> amount of load in runnable_load_avg after the dequeue so another cpu
> will be chosen. But this explanation seems to be the opposite of
On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote:
> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 8fb4d1942c14..4a2d3ff772f8 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3142,7 +314
On 29 September 2016 at 18:15, Dietmar Eggemann
wrote:
> On 28/09/16 14:13, Vincent Guittot wrote:
>> Le Wednesday 28 Sep 2016 à 05:27:54 (-0700), Vincent Guittot a écrit :
>>> On 28 September 2016 at 04:31, Dietmar Eggemann
>>> wrote:
On 28/09/16 12:19, Peter Zijlstra wrote:
> On Wed, S
On Wed, 28 Sep, at 08:37:31PM, Matt Fleming wrote:
>
> I'm away on FTO right now. I can test this when I return on Friday.
I haven't had chance to review your patch or the other emails in this
thread yet, but I ran the patch on my test machine and it also
restores performance. I'll run it through
On 28/09/16 14:13, Vincent Guittot wrote:
> Le Wednesday 28 Sep 2016 à 05:27:54 (-0700), Vincent Guittot a écrit :
>> On 28 September 2016 at 04:31, Dietmar Eggemann
>> wrote:
>>> On 28/09/16 12:19, Peter Zijlstra wrote:
On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>
On Wed, 28 Sep, at 12:14:22PM, Peter Zijlstra wrote:
>
> Which suggests we do something like the below (not compile tested or
> anything, also I ran out of tea again).
I'm away on FTO right now. I can test this when I return on Friday.
Funnily enough, I now remember that I already sent a fix for
On 28/09/16 12:19, Peter Zijlstra wrote:
> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>> On 28/09/16 11:14, Peter Zijlstra wrote:
>>> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
[...]
>> I'm afraid that with accurate timing we will get the same situation t
Le Wednesday 28 Sep 2016 à 05:27:54 (-0700), Vincent Guittot a écrit :
> On 28 September 2016 at 04:31, Dietmar Eggemann
> wrote:
> > On 28/09/16 12:19, Peter Zijlstra wrote:
> >> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
> >>> On 28/09/16 11:14, Peter Zijlstra wrote:
> >>>
On 28 September 2016 at 04:31, Dietmar Eggemann
wrote:
> On 28/09/16 12:19, Peter Zijlstra wrote:
>> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>>> On 28/09/16 11:14, Peter Zijlstra wrote:
On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
>
> [...]
>
>>> Not
On 28 September 2016 at 04:46, Vincent Guittot
wrote:
> On 28 September 2016 at 04:31, Dietmar Eggemann
> wrote:
>> On 28/09/16 12:19, Peter Zijlstra wrote:
>>> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
On 28/09/16 11:14, Peter Zijlstra wrote:
> On Fri, Sep 23, 20
On 28 September 2016 at 04:31, Dietmar Eggemann
wrote:
> On 28/09/16 12:19, Peter Zijlstra wrote:
>> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>>> On 28/09/16 11:14, Peter Zijlstra wrote:
On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
>
> [...]
>
>>> Not
On 28/09/16 12:19, Peter Zijlstra wrote:
> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>> On 28/09/16 11:14, Peter Zijlstra wrote:
>>> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
[...]
>> Not sure what you mean by 'after fixing' but the se is initialized wi
On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
> On 28/09/16 11:14, Peter Zijlstra wrote:
> > On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >> index 8fb4d1942c14..4a2d3ff772f8 100644
> >> --- a/kernel/s
On 28/09/16 11:14, Peter Zijlstra wrote:
> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 8fb4d1942c14..4a2d3ff772f8 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -3142,7 +3142,7 @@ enqueue_en
On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8fb4d1942c14..4a2d3ff772f8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3142,7 +3142,7 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct
> s
On Tue, 27 Sep, at 02:48:31PM, Dietmar Eggemann wrote:
>
> I think Matt is talking about the fact that the cfs->runnable_load_avg
> value is 0 once the hackbench task is initially dequeued.
Yes.
> Without this patch the value of se->avg.load_avg (e.g. both times 1002)
> is exactly the same when
On Fri, 23 Sep, at 04:30:25PM, Vincent Guittot wrote:
>
> Does it mean that you can see the perf drop that you mention below
> because load is decayed to 1002 instead of staying to 1024 ?
The performance drop comes from the fact that enqueueing/dequeueing a
task with load 1002 during fork() resu
On 23/09/16 15:30, Vincent Guittot wrote:
> Hi Matt,
>
> On 23 September 2016 at 13:58, Matt Fleming wrote:
>> Since commit 7dc603c9028e ("sched/fair: Fix PELT integrity for new
>> tasks") ::last_update_time will be set to a non-zero value in
>> post_init_entity_util_avg(), which leads to p->se.a
Hi Matt,
On 23 September 2016 at 13:58, Matt Fleming wrote:
> Since commit 7dc603c9028e ("sched/fair: Fix PELT integrity for new
> tasks") ::last_update_time will be set to a non-zero value in
> post_init_entity_util_avg(), which leads to p->se.avg.load_avg being
> decayed on enqueue before the t
Since commit 7dc603c9028e ("sched/fair: Fix PELT integrity for new
tasks") ::last_update_time will be set to a non-zero value in
post_init_entity_util_avg(), which leads to p->se.avg.load_avg being
decayed on enqueue before the task has even had a chance to run.
For a NICE_0 task the sequence of e
45 matches
Mail list logo
