linux-kernel - Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr

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:   Thu, 23 Sep 2021 11:21:58 +0200
From:   Mike Galbraith <efault@....de>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Aubrey Li <aubrey.li@...ux.intel.com>,
        Barry Song <song.bao.hua@...ilicon.com>,
        Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to
 nr_running

On Thu, 2021-09-23 at 10:40 +0200, Vincent Guittot wrote:
>
> a 100us value should even be enough to fix Mel's problem without
> impacting common wakeup preemption cases.

It'd be nice if it turn out to be something that simple, but color me
skeptical.  I've tried various preemption throttling schemes, and while
it was trivial to get promising results, my scheme always managed to
harm something.  Everything I ever tried, I ended up tossing.

	-Mike