Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 16 Sep 2022 18:49:39 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Tim Chen <tim.c.chen@linux.intel.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Tim Chen <tim.c.chen@intel.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Juri Lelli <juri.lelli@redhat.com>,
        "Rik van Riel" <riel@surriel.com>, Aaron Lu <aaron.lu@intel.com>,
        Abel Wu <wuyun.abel@bytedance.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        "Yicong Yang" <yangyicong@hisilicon.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        Ingo Molnar <mingo@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] sched/fair: Choose the CPU where short task is
 running during wake up
Message-ID: <YyRUw4gmxMwgo4Zc@chenyu5-mobl1>
References: <20220915165407.1776363-1-yu.c.chen@intel.com>
 <bb7dd6ac32403e96943a6e51c60e72960c2942fd.camel@linux.intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <bb7dd6ac32403e96943a6e51c60e72960c2942fd.camel@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ilu+UfuWk43rtjKPG2Hdkj0VW8wO+F3+lJd7fVk5/QwsrIBdjubY5nPcgWz7?=
 =?us-ascii?Q?zInP1mWslU/s7+hPDx8gshglVAYbr3GDY5tyKiBaYIE/7j6e7vTtgMgjRq22?=
 =?us-ascii?Q?SdpmdX7ntsyMYt2MX6r0Q07XgNEeIhOSfeq9m7KJ1BhEPQbNGU4UnVkjt0QA?=
 =?us-ascii?Q?KfkVt4ZMb3ajSTNsoDCrvE0cgEqOVxbYuVwlHGxzazVjm9p1NvL4k8O7F3UP?=
 =?us-ascii?Q?eARSUia+6+ESxmxIbyqlNRE2UF60W6HJjJ3QTwi0b2KlzFEzDvFDdAhz164G?=
 =?us-ascii?Q?OHIJbvsDZi6y53yO1HzBnrKKQju/3RnlUrThbkFM3zVfQ+PuTUQuKvJ0KWr9?=
 =?us-ascii?Q?LnQRBkMqTBt8QyiFWuYR/m+PfkYtBE1uICUjwHNJ/2mCjbi3pYCYFruzqKiY?=
 =?us-ascii?Q?pDqcwPDRlcfZy94ANI3ADw6TSK02dS07SWT5uIMqLTC8pbJsSWeJBTReXvyE?=
 =?us-ascii?Q?T//bOzvBma+QmXmN8RqqvYrsVF9p/e5E+pCgsBQB/f9Q2NVfpQzOHWRb5IV6?=
 =?us-ascii?Q?nx+6Lc5XVB51U+DIZZmzRcVjRbcke6cuOeyUFU5kWdZFypmDj0NxwfQpSrQk?=
 =?us-ascii?Q?xIQBGJSWQZ9xzBRj8TUF6zNSZ8XJ+3nYeQQs51xpVlR2kQCh7neAm+b0diLn?=
 =?us-ascii?Q?BFOhh+U6qlmOTPABoEY722RHxlGZDSqm6pr1wZcoJ0UeVSL83EMcyl1hdfnW?=
 =?us-ascii?Q?FDZBB9QhbTuGdtCDRgS64Yv9PvUzkM2eG0BTPSccEcGJr0+fN9oSwlxqrqB7?=
 =?us-ascii?Q?iDZ996sOdfXcTxg7lZsjQFYx9nlIcUyy2BcQI+rp3jTW4SaFcx+9q1ClkjnK?=
 =?us-ascii?Q?GWawMIrJsgFsde2nyNbmOOeeBijt7M498C1HE2glGbex1ZQTEIbNoCdNdlUR?=
 =?us-ascii?Q?hCYPzQqIOolngGhN5eUuXgBYycOtNIUBJTPlz2HcjCmP4Mdf31/1wwJiR+yU?=
 =?us-ascii?Q?uoMKpKcfzW3bE1/hgg9opsve3pIe6kxqLSgSwV34dxCXm5F9ayXnCWQ+mp6p?=
 =?us-ascii?Q?fhHG0gZRRK9LVR/KPIhvA8fYEoNV+USXmugHlgh39J0KauLvXZz5MoX+r5sA?=
 =?us-ascii?Q?7KOQl4ObjLtGBdDKEhcmetvoW2FIsyuOetCIBpPR9rmI4Xi2ENXfgM+io3L/?=
 =?us-ascii?Q?JnS5bZtIRn0tfA8+LBysuiWWT6LkuV7keVrCoN3eixnwJGEVS2ruBZgrBuy+?=
 =?us-ascii?Q?Ce1sQ/J/6HAYiXyp8savc3qnjLdGMgsXIyqH6yu8K8jyn6qSmQ5ugvigXZFV?=
 =?us-ascii?Q?i2ksegsy8Bkk758JFo0fGdT9sJ7gIKZmBNP1DZ4Mqanq/FypPf+MNpdR3NnC?=
 =?us-ascii?Q?VP9edtscQkEB3Zp3m9NRLWXDdT4NlCJvXKsn7Wv+RJHMz3AhGuLKHRkucNiW?=
 =?us-ascii?Q?2f4eINnpNObUA7ymzGt4W0F2KN9JzzOQRNDRYeFRlRfkmdZZ/GpQ4tjwov+b?=
 =?us-ascii?Q?C62lYmkWpPO+9q0V8bA1UvVeztL0KRyKOSkpMpU40v/UOLDVC2ja6tvpcpm1?=
 =?us-ascii?Q?ibBW0hlM81bc4ZxCZ/KGNZUe8tXRCi5inN2iLbz0FEUsKJHnYz01fGbkHfQw?=
 =?us-ascii?Q?tiOGkwlZ7pOXN87kS6X2rYpDO0Il4c/rWg/TZhcf?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ba6d3a1-4439-4bc8-80e7-08da97d13517
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2022 10:50:02.2288
 (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: NCaDa/SZMsfy7XU/bMdkr8BlxAaSBqWOslxfkirXh0YNgVD53h0zztugA9P92vpM9SEadanIGk1Y6ITeBLGHBQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7313
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2022-09-15 at 10:10:25 -0700, Tim Chen wrote:
> On Fri, 2022-09-16 at 00:54 +0800, Chen Yu wrote:
> > 
> > +/*
> > + * If a task switches in and then voluntarily relinquishes the
> > + * CPU quickly, it is regarded as a short running task.
> > + * sysctl_sched_min_granularity is chosen as the threshold,
> > + * as this value is the minimal slice if there are too many
> > + * runnable tasks, see __sched_period().
> > + */
> > +static int is_short_task(struct task_struct *p)
> > +{
> > +	return (p->se.sum_exec_runtime <=
> > +		(p->nvcsw * sysctl_sched_min_granularity));
> > +}
> > +
> >  /*
> >   * The purpose of wake_affine() is to quickly determine on which CPU we can run
> >   * soonest. For the purpose of speed we only consider the waking and previous
> > @@ -6050,7 +6063,8 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync)
> >  	if (available_idle_cpu(this_cpu) && cpus_share_cache(this_cpu, prev_cpu))
> >  		return available_idle_cpu(prev_cpu) ? prev_cpu : this_cpu;
> >  
> > -	if (sync && cpu_rq(this_cpu)->nr_running == 1)
> > +	if ((sync && cpu_rq(this_cpu)->nr_running == 1) ||
> > +	    is_short_task(cpu_curr(this_cpu)))
> >  		return this_cpu;
> >  
> >  	if (available_idle_cpu(prev_cpu))
> > @@ -6434,6 +6448,21 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, bool
> >  			/* overloaded LLC is unlikely to have idle cpu/core */
> >  			if (nr == 1)
> >  				return -1;
> > +
> > +			/*
> > +			 * If nr is smaller than 60% of llc_weight, it
> > +			 * indicates that the util_avg% is higher than 50%.
> > +			 * This is calculated by SIS_UTIL in
> > +			 * update_idle_cpu_scan(). The 50% util_avg indicates
> > +			 * a half-busy LLC domain. System busier than this
> > +			 * level could lower its bar to choose a compromised
> > +			 * "idle" CPU. If the waker on target CPU is a short
> > +			 * task and the wakee is also a short task, pick
> > +			 * target directly.
> > +			 */
> > +			if (!has_idle_core && (5 * nr < 3 * sd->span_weight) &&
> > +			    is_short_task(p) && is_short_task(cpu_curr(target)))
> 
> Should we check if target's rq's nr_running is 1, and if there's pending waking
> task before picking it?
>
Yes we can consider the two factors, then the criteria to pick up a target CPU
would be more strict. After taking nr_running and the pending wakeup request into
consideration, I think it would be a variant of WF_SYNC and we can get rid of
'system should be busy' restriction. I'll do some test in this direction.

thanks,
Chenyu
> > +				return target;
> >  		}
> >  	}
> >  
> 
> Thanks.
> 
> Tim
>