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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Oct 2016 11:01:07 +0100
From:   Matt Fleming <matt@...eblueprint.co.uk>
To:     Wanpeng Li <kernellwp@...il.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mike Galbraith <umgwanakikbuti@...il.com>,
        Yuyang Du <yuyang.du@...el.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>
Subject: 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 reply in this thread?

Both my patch and Peter's patch cause issues with low cpu machines. In
<20161004201105.GP16071@...eblueprint.co.uk> 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 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
load balancing decisions would speed up this sort of research.