[<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