Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Date:   Tue, 12 Sep 2023 20:32:25 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     K Prateek Nayak <kprateek.nayak@amd.com>
CC:     Tim Chen <tim.c.chen@intel.com>, Aaron Lu <aaron.lu@intel.com>,
        "Dietmar Eggemann" <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        "Daniel Bristot de Oliveira" <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Ingo Molnar <mingo@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [RFC PATCH 2/2] sched/fair: skip the cache hot CPU in
 select_idle_cpu()
Message-ID: <ZQBaWRCmMOvIGmem@chenyu5-mobl2.ccr.corp.intel.com>
References: <cover.1694397335.git.yu.c.chen@intel.com>
 <d49cf5748aa7c6d69580315d2373a9eafa21c21f.1694397335.git.yu.c.chen@intel.com>
 <31c910c2-717d-b86c-4e08-5c94383682e8@amd.com>
 <ZP7ptt70uF10wxlg@chenyu5-mobl2>
 <5b35ae2b-a401-2489-4b3a-a03e8284d138@amd.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5b35ae2b-a401-2489-4b3a-a03e8284d138@amd.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mW7pWiff9leMjYKZpn9FdbXV3dsKKDc9p3julfX+lO+nESkxR6MYFqoFCznx?=
 =?us-ascii?Q?CrhbhklYPNZkHCpcBKykyRBltmQGrRm3Mx/nW+zqqKtK0u1McZj8JqpxhR3P?=
 =?us-ascii?Q?+svB4VWNj715rcLyISjtDvs4zNZBQLyGJkSJn5dRpocByjH+EdnhHTj9LAjX?=
 =?us-ascii?Q?lv1/iVC0P6nHS6uMALgFHqTg+mqqyD9S1+zycXu5u7m+qJUCjTO498CPbb66?=
 =?us-ascii?Q?420A6cd+sOMCs0xAoaBP6XdBjmuj1MY5DPEH+ZWsLMHFPrfyEvGFM389TO3o?=
 =?us-ascii?Q?Ng9Tyk6XknQh7zjisBtCIpnCjmk9snjvhG2iPA6X7jXcvAMd4ZSDQ/rxYRRa?=
 =?us-ascii?Q?aQVJ++I5mBwSb1xjf6tEhAdYm1bFr/o3pXbM63DoMs4r8C6pyYq+j/UmYgc1?=
 =?us-ascii?Q?Ycl9IPdLd7FnZbx9VaYVqEwSX3tSgIcRh1KUrga+RIv0k7NOIhTky8r1tZZO?=
 =?us-ascii?Q?BULSD1GXpiR7XP0nkO6Vj5GlsxB6bA1+nDM89PjMnasbZcYBWZ/xiGuDuU4t?=
 =?us-ascii?Q?54q0PfL4iARyewc2srCajRnI4pw3Hy0Uk9F/rUcOZmC7Q40i0e9gq650z/ki?=
 =?us-ascii?Q?DbMOH95GEacRrSc/YOOw2r+/n5Xv7z8VpEMeMHNUOoxRFMh9yFK3klP+Wb0q?=
 =?us-ascii?Q?sSQLhaBWKuGktGJLl3lJGn3ofstngAdk/cLTRHF2NT4aFehGRH4d9fJNAb3F?=
 =?us-ascii?Q?zZ/oMQEOcXG3KE6+pE3RXsjaB0h9ue5KW+gOAN5sK8vNsJI+40/muQDfLXGU?=
 =?us-ascii?Q?oYld9yEeN73VLpF21g2fV3iso6nVqymfYzDV9+2b2iZldrFy6kbPxvaAi5oH?=
 =?us-ascii?Q?HAEOIcURpUfr8ktIqbKzO72CvlO8Lek2UgYdJLNDcR2ExhVYX1WqHX+BlSj9?=
 =?us-ascii?Q?Qjm5Aq1n+eP/zx7ars7ncnxmP0zvYgDW8arjh5Kyq9XDfSbxlH+kMWm9dEc0?=
 =?us-ascii?Q?0TAiseEHjL75HZCmUIFyi2vPryc+bvflkfULCVSPzmkfYuD845DpHuebPz2s?=
 =?us-ascii?Q?GDQab9jkXixCl253pHaBmiiZnm8W79DSjvO7FTRtrRGeEgeEji8h28cbL4O4?=
 =?us-ascii?Q?Qud1qkfXRUpJD7taJoCatw5/IuCBDQ1bEzu3Tq2z/JCfBD8815cTmE6xVe73?=
 =?us-ascii?Q?uB+gOd/zluR01O2CqD826HUyDkweAOhqodHeuDDcRk9M+51Fu49yqr/z+YES?=
 =?us-ascii?Q?CxUzU43E6HaHXkW2JHmFR5w04FQr7HmNdNOlI64Zeuqfj7UujUQ6TeQoBq76?=
 =?us-ascii?Q?lQLlaEmPb/l1lpWDt41B4/GCxzLCM2WqVVohNjAi/9NBoOoz6G7uydQWsmGn?=
 =?us-ascii?Q?YS4cqicL6q5U7NYWUWxNl9mOZ54NGtermS5jdVzJzCfpp1IGXFd+yESCAEVU?=
 =?us-ascii?Q?Y1nlIt/ntt/q4+DKp0thYEm8bZPDUr4+M90hyJlWVHl8fo9cKVY8Y15OVuxR?=
 =?us-ascii?Q?eRK5qaWHUfqSP0R1FLwR9fKNX0mVz8g3oRpAZiI1KnjNi7LaBW+w14fHh9CP?=
 =?us-ascii?Q?W/zSSJOlOjjtlGiAm6DOLBZ+cdoNo6NRxN3bngEcVF+lkRCIX4/sH9bFMxmB?=
 =?us-ascii?Q?TY81xua74jiWCMKDoNdvp0FKojt6tqpgPyHi68D9?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f7e32e32-fb26-4dc8-3f6d-08dbb38c5d47
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2023 12:32:44.6764
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: CQzyNI+b/XxTayp80to0mamWOmdve72CRx6mJ/eKmjox3Wp9Hox4Ewvjh0BUeqTYrIqUKbwXOQNDId1+OWp8rQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4535
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 12 Sep 2023 05:32:55 -0700 (PDT)

Hi Prateek,

On 2023-09-12 at 08:35:12 +0530, K Prateek Nayak wrote:
> Hello Chenyu,
> 
> On 9/11/2023 3:49 PM, Chen Yu wrote:
> > Hi Prateek,
> > 
> > thanks for your review,
> > 
> > On 2023-09-11 at 13:59:10 +0530, K Prateek Nayak wrote:
> >> Hello Chenyu,
> >>
> >> On 9/11/2023 8:20 AM, Chen Yu wrote:
> >>>  [..snip..]
> >>>  kernel/sched/fair.c     | 30 +++++++++++++++++++++++++++---
> >>>  kernel/sched/features.h |  1 +
> >>>  kernel/sched/sched.h    |  1 +
> >>>  3 files changed, 29 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >>> index e20f50726ab8..fe3b760c9654 100644
> >>> --- a/kernel/sched/fair.c
> >>> +++ b/kernel/sched/fair.c
> >>> @@ -6629,6 +6629,21 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> >>>  	hrtick_update(rq);
> >>>  	now = sched_clock_cpu(cpu_of(rq));
> >>>  	p->se.prev_sleep_time = task_sleep ? now : 0;
> >>> +#ifdef CONFIG_SMP
> >>> +	/*
> >>> +	 * If this rq will become idle, and dequeued task is
> >>> +	 * a short sleeping one, check if we can reserve
> >>> +	 * this idle CPU for that task for a short while.
> >>> +	 * During this reservation period, other wakees will
> >>> +	 * skip this 'idle' CPU in select_idle_cpu(), and this
> >>> +	 * short sleeping task can pick its previous CPU in
> >>> +	 * select_idle_sibling(), which brings better cache
> >>> +	 * locality.
> >>> +	 */
> >>> +	if (sched_feat(SIS_CACHE) && task_sleep && !rq->nr_running &&
> >>> +	    p->se.sleep_avg && p->se.sleep_avg < sysctl_sched_migration_cost)
> >>> +		rq->cache_hot_timeout = now + p->se.sleep_avg;
> >>> +#endif
> >>>  }
> >>>  
> >>>  #ifdef CONFIG_SMP
> >>> @@ -6982,8 +6997,13 @@ static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p
> >>>  static inline int __select_idle_cpu(int cpu, struct task_struct *p)
> >>>  {
> >>>  	if ((available_idle_cpu(cpu) || sched_idle_cpu(cpu)) &&
> >>> -	    sched_cpu_cookie_match(cpu_rq(cpu), p))
> >>> +	    sched_cpu_cookie_match(cpu_rq(cpu), p)) {
> >>> +		if (sched_feat(SIS_CACHE) &&
> >>> +		    sched_clock_cpu(cpu) < cpu_rq(cpu)->cache_hot_timeout)
> >>> +			return -1;
> >>
> >> Just wondering,
> >>
> >> Similar to how select_idle_core() caches the "idle_cpu" if it ends up
> >> finding one in its search for an idle core, would returning a "cache-hot
> >> idle CPU" be better than returning previous CPU / current CPU if all
> >> idle CPUs found during the search in select_idle_cpu() are marked
> >> cache-hot?
> >>
> > 
> > This is a good point, we can optimize this further. Currently I only
> > send a simple version to desmonstrate how we can leverage the task's
> > sleep time.
> > 
> >> Speaking of cache-hot idle CPU, is netperf actually more happy with
> >> piling on current CPU?
> > 
> > Yes. Per my previous test, netperf of TCP_RR/UDP_RR really likes to
> > put the waker and wakee together.
> > 
> >> I ask this because the logic seems to be
> >> reserving the previous CPU for a task that dislikes migration but I
> >> do not see anything in the wake_affine_idle() path that would make the
> >> short sleeper proactively choose the previous CPU when the wakeup is
> >> marked with the WF_SYNC flag. Let me know if I'm missing something?
> >>
> > 
> > If I understand correctly, WF_SYNC is to let the wakee to woken up
> > on the waker's CPU, rather than the wakee's previous CPU, because
> > the waker goes to sleep after wakeup. SIS_CACHE mainly cares about
> > wakee's previous CPU. We can only restrict that other wakee does not
> > occupy the previous CPU, but do not enhance the possibility that
> > wake_affine_idle() chooses the previous CPU.
> 
> Correct me if I'm wrong here,
> 
> Say a short sleeper, is always woken up using WF_SYNC flag. When the
> task is dequeued, we mark the previous  CPU where it ran as "cache-hot"
> and restrict any wakeup happening until the "cache_hot_timeout" is
> crossed. Let us assume a perfect world where the task wakes up before
> the "cache_hot_timeout" expires. Logically this CPU was reserved all
> this while for the short sleeper but since the wakeup bears WF_SYNC
> flag, the whole reservation is ignored and waker's LLC is explored.
> 

Ah, I see your point. Do you mean, because the waker has a WF_SYNC, wake_affine_idle()
forces the short sleeping wakee to be woken up on waker's CPU rather the
wakee's previous CPU, but wakee's previous has been marked as cache hot
for nothing?

> Should the timeout be cleared if the wakeup decides to not target the
> previous CPU? (The default "sysctl_sched_migration_cost" is probably
> small enough to curb any side effect that could possibly show here but
> if a genuine use-case warrants setting "sysctl_sched_migration_cost" to
> a larger value, the wakeup path might be affected where lot of idle
> targets are overlooked since the CPUs are marked cache-hot forr longer
> duration)
> 
> Let me know what you think.
> 

This makes sense. In theory the above logic can be added in
select_idle_sibling(), if target CPU is chosen rather than
the previous CPU, the previous CPU's cache hot flag should be
cleared.

But this might bring overhead. Because we need to grab the rq
lock and write to other CPU's rq, which could be costly. It
seems to be a trade-off of current implementation. On the other
hand, if the user sets the sysctl_sched_migration_cost to a quite
large value:
1. Without SIS_CACHE, there is no task migration.
2. With SIS_CACHE enabled, all idle CPUs are cache hot and be skipped
   in select_idle_cpu(), the wakee will be woken up locally.
It seems to be of the same effect, so there is no much impact
to wakeup behavior I suppose.

thanks,
Chenyu