linux-kernel - Re: [PATCH] sched, fair: Allow a per-cpu kthread waking a task to stack on the same CPU

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>] [day] [month] [year] [list]

Message-ID: <20200128134148.GB3466@techsingularity.net>
Date:   Tue, 28 Jan 2020 13:41:48 +0000
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Dave Chinner <david@...morbit.com>,
        Ingo Molnar <mingo@...hat.com>, Tejun Heo <tj@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched, fair: Allow a per-cpu kthread waking a task to
 stack on the same CPU

On Tue, Jan 28, 2020 at 09:08:37PM +0800, Hillf Danton wrote:
> > Functionally it works, it's just slow. There is a cost to migration and
> > a cost to exiting from idle state and ramping up the CPU frequency.
> > 
> Yeah we need to pay some costs but are not they compensated by the ping
> and pong that waker and wakee are happy to play for ten minutes on
> different cpus sharing cache if you have no way to migrate waker?
> 

I could get into it depth but the changelog already mentions the cpufreq
implications and the consequences of round-robining around the machine
as a side-effect of how select_idle_sibling works. The data indicates
that we are not compensated by the migrations.

> Or back to the kworker case, a tradeoff needs to make between making kworker
> able to run on cache-sharing cpus and adding scheduling heuristics. IOW
> is cache affinity the key to the problem?
> 

The kworker is already running on CPUs sharing cache. That is not the
central issue.

-- 
Mel Gorman
SUSE Labs