Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC PATCH 3/3] sched: introduce tunables to control soft
 affinity
To:     Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc:     linux-kernel@vger.kernel.org, peterz@infradead.org,
        mingo@redhat.com, tglx@linutronix.de, prakash.sangappa@oracle.com,
        dhaval.giani@oracle.com, daniel.lezcano@linaro.org,
        vincent.guittot@linaro.org, viresh.kumar@linaro.org,
        tim.c.chen@linux.intel.com, mgorman@techsingularity.net
References: <20190626224718.21973-1-subhra.mazumdar@oracle.com>
 <20190626224718.21973-4-subhra.mazumdar@oracle.com>
 <20190718100816.GA19218@linux.vnet.ibm.com>
From:   Subhra Mazumdar <subhra.mazumdar@oracle.com>
Message-ID: <81034dd8-4074-e716-c3e8-5a23cbb6bb8d@oracle.com>
Date:   Fri, 19 Jul 2019 12:53:19 +0530
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0)
 Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190718100816.GA19218@linux.vnet.ibm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 7/18/19 3:38 PM, Srikar Dronamraju wrote:
> * subhra mazumdar <subhra.mazumdar@oracle.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@oracle.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.