Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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.. > >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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.. > >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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, >> >>

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 > >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 > >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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()

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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()

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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(),

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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/

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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/

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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: >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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: >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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: > > [...] > >>>

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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,

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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: > > [...] > >>>

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 > >> ---

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 > >> ---

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 @@

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 @@

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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()

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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()

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 >>

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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 >

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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

[PATCH] sched/fair: Do not decay new task load on first enqueue

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

[PATCH] sched/fair: Do not decay new task load on first enqueue

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