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

[Vincent Guittot]

On 10 October 2016 at 12:01, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> 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 machines (4 or 8) to
>> regress against your another reply in this thread?
>
> Both my patch and Peter's patch cause issues with low cpu machines. In
> <20161004201105.GP16071@xxxxxxxxxxxxxxxxxxx> I said,
>
>  "This patch causes some low cpu machines (4 or 8) to regress. It turns
>   out they regress with my patch too."
>
> Have I misunderstood your question?
>
> I ran out of time to investigate this last week, though I did try all
> proposed patches, including Vincent's, and none of them produced wins
> across the board.

I have tried to reprocude your issue on my target an hikey board (ARM
based octo cores) but i failed to see a regression with commit
7dc603c9028e. Neverthless, i can see tasks not been well  spread
during fork as you mentioned. So I have studied a bit more the
spreading issue during fork last week and i have a new version of my
proposed patch that i'm going to send soon. With this patch, i can see
a good spread of tasks  during the fork sequence and some kind of perf
improvement even if it's bit difficult as the variance is quite
important with hackbench test so it's mainly an improvement of
repeatability of the result

>
> I should get a bit further this week.
>
> Vincent, Dietmar, did you guys ever get around to submitting your PELT
> tracepoint patches? Getting some introspection into the scheduler's

My tarcepoint are not in a shape to be submitted and would need a
cleanup as some are more hacks for debugging than real trace events.
Nevertheless, i can push them on a git branch if they can be useful
for someone


> load balancing decisions would speed up this sort of research.