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] [day] [month] [year] [list]
Message-ID: <81034dd8-4074-e716-c3e8-5a23cbb6bb8d@oracle.com>
Date:   Fri, 19 Jul 2019 12:53:19 +0530
From:   Subhra Mazumdar <subhra.mazumdar@...cle.com>
To:     Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org,
        mingo@...hat.com, tglx@...utronix.de, prakash.sangappa@...cle.com,
        dhaval.giani@...cle.com, daniel.lezcano@...aro.org,
        vincent.guittot@...aro.org, viresh.kumar@...aro.org,
        tim.c.chen@...ux.intel.com, mgorman@...hsingularity.net
Subject: Re: [RFC PATCH 3/3] sched: introduce tunables to control soft
 affinity


On 7/18/19 3:38 PM, Srikar Dronamraju wrote:
> * subhra mazumdar <subhra.mazumdar@...cle.com> [2019-06-26 15:47:18]:
>
>> For different workloads the optimal "softness" of soft affinity can be
>> different. Introduce tunables sched_allowed and sched_preferred that can
>> be tuned via /proc. This allows to chose at what utilization difference
>> the scheduler will chose cpus_allowed over cpus_preferred in the first
>> level of search. Depending on the extent of data sharing, cache coherency
>> overhead of the system etc. the optimal point may vary.
>>
>> Signed-off-by: subhra mazumdar <subhra.mazumdar@...cle.com>
>> ---
> Correct me but this patchset only seems to be concentrated on the wakeup
> path, I don't see any changes in the regular load balancer or the
> numa-balancer. If system is loaded or tasks are CPU intensive, then wouldn't
> these tasks be moved to cpus_allowed instead of cpus_preferred and hence
> breaking this soft affinity.
>
The new idle is purposefully unchanged, if threads get stolen to the allowed
set from the preferred set that's intended, together with the enqueue side
it will achieve softness of affinity.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ