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:   Sat, 22 Oct 2022 23:08:33 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Vincent Guittot <vincent.guittot@linaro.org>
CC:     <mingo@redhat.com>, <peterz@infradead.org>,
        <juri.lelli@redhat.com>, <dietmar.eggemann@arm.com>,
        <rostedt@goodmis.org>, <bsegall@google.com>, <mgorman@suse.de>,
        <bristot@redhat.com>, <vschneid@redhat.com>,
        <linux-kernel@vger.kernel.org>, <parth@linux.ibm.com>,
        <qais.yousef@arm.com>, <chris.hyser@oracle.com>,
        <valentin.schneider@arm.com>, <patrick.bellasi@matbug.net>,
        <David.Laight@aculab.com>, <pjt@google.com>, <pavel@ucw.cz>,
        <tj@kernel.org>, <qperret@google.com>,
        <tim.c.chen@linux.intel.com>, <joshdon@google.com>, <timj@gnu.org>
Subject: Re: [PATCH v5 4/7] sched/fair: Take into account latency priority at
 wakeup
Message-ID: <Y1QHcZSmKAX2SWgu@chenyu5-mobl1>
References: <20220925143908.10846-1-vincent.guittot@linaro.org>
 <20220925143908.10846-5-vincent.guittot@linaro.org>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220925143908.10846-5-vincent.guittot@linaro.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7Y5q9CYF9jSbF8+avFvYMjUbmSBUK66ilAqrFwIQpWCiUbF5s7rg4N8IzdN/?=
 =?us-ascii?Q?ntr1thv5+aTXURp6z5qQystN4SKp9Mrc/66B5gf4KrXJ1G5g1HMHlilJl8KT?=
 =?us-ascii?Q?iBkkU4hK144lBm6b5ptf+dzqvEThizkL6ZU55lFh59CIBji4rikWBGKmt/vg?=
 =?us-ascii?Q?LO1FM97tzUoI9r7i9CHR2v1C5/oDs0U4EPTRnCwO/H6rk/fpjD46lm+UGSl5?=
 =?us-ascii?Q?hjrblO9u3RcKjrmKFca1M0thIAtZSYFUlhTPGq+62uoqyRAAgt3numvLjJCM?=
 =?us-ascii?Q?787b8x4iR2WknPrldEQbT0sWcTtwPia7cuPf7bgW6btV6ZeDmlQPVqMcAzq7?=
 =?us-ascii?Q?4TcBwir24I3qeoTtJRpOlxXdI1CA1GpKhlGGgkGGEyfJWKbBTw5X+7m6Ayxv?=
 =?us-ascii?Q?NYw837jxT+iQYZinhLn75dowNsfAqkpgv4MXPzVEmQ86XH0TFxPTnIcjtifF?=
 =?us-ascii?Q?9KBhGPgYy+q2CsQCjudB+FtF8sul+1XhG1urTBeEkkRx1fwB9OzMcoHeBq9P?=
 =?us-ascii?Q?05bq73VhD+VhOzRwshneZ5b7seAQqb+qnKpKD6pzUmHu0F1UFQ8M2y90z0V6?=
 =?us-ascii?Q?HWKjl6CMapdt0qhp7szYbN4xWte2ntmwBDaziB9hLIAXyuJD47YxuZkEcRHT?=
 =?us-ascii?Q?rYSE1zhwXvCL7Vb2vCI6U+nZR9EJiqXG+7cd/+1WeBk8LB/cJzIuY3kavslh?=
 =?us-ascii?Q?3r92lxnRlEuCS5A3+wgIt81XaSaFRit7OKxEtUi3RBQqbJrHWemhdSvSq8MH?=
 =?us-ascii?Q?x4PC6VFnChWY/Yk+wGbG/6bsfLGNCbEaTbqIKb8+e9hWeT5JY0A0jZbmuiuQ?=
 =?us-ascii?Q?uhzPwXY6HkQEDeMY4w9g3PrLhR6uajUhjDPTlwJnQcXoAS5hvPn8aAiQTULy?=
 =?us-ascii?Q?ibkHRAskXRH+9ICapPxKUdTNHLosMcBBTcq1yUZw9zpTrBwd3IBV4by3JeDg?=
 =?us-ascii?Q?GPR3/Y+97BVBa4SfqEzmUclRzxBswV5g7mgcC2eTfe8LcW5xevHKO0lNi6cR?=
 =?us-ascii?Q?pWmxaDQrRP8qy7DkZ536RVaSjjyFmth49+jiCTKFWcNPPPA91Ydm8qmNVAJl?=
 =?us-ascii?Q?LzDxCYuoJ4swJM6Yot9ZFAQMqx8t++qEi7Vm+rWUrDFZ9p2xgzXnsDPvvXpK?=
 =?us-ascii?Q?JCDjMrWFty35U8ujjVsK3JsMmIu3hYjNfmYwnS9fkETsougozt5076UsNgmV?=
 =?us-ascii?Q?qAdNd6izy9RPB6WD8rv9gutWIe8x5shYOOwMAkEgzvtYJkX8P8FLj16kGfN8?=
 =?us-ascii?Q?8I6eHRykXpvuJgeIhK8QywdgQy7+O0KCaKEfZEls2wf5ZYv1gJe9/iuBWAn2?=
 =?us-ascii?Q?4vKp0+kfhmYGYXIF15rCpL2Gr9XX7c95/fHd67yH+mf5fZR4hlljBxzI2vcS?=
 =?us-ascii?Q?qYUk/W4Eli0Pb47NOIRNtRvda1EuJWnKNzaoYmnmG59UZ6Kt2CM6C/vMCDhK?=
 =?us-ascii?Q?B2mwAE93l28p+AhiOlga6D7Pqs5zHttS2GltnGPTabICmzd8HHEJ8xrEV7kl?=
 =?us-ascii?Q?oOeqNHMpheV5jadeA9ITPUCLmWL+nFKEuzPi5ReHR86994JWXlMn75/59t3O?=
 =?us-ascii?Q?Na8TlUPFmzzK3Oq/ss83pqraFCtlqJ6ZHtBiqvJr?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 07cec82c-f599-413f-1f59-08dab43f569a
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2022 15:08:55.8351
 (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: fDOglhghSJl5YVhIlH27Xm81x4wU6K7TIS/n8vu8zM+9ahzF4RRiUCb1k6u6CwdiF/vK09XK5fuXl5WRVJ6msw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4635
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        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

Hi Vincent,
On 2022-09-25 at 16:39:05 +0200, Vincent Guittot wrote:
[...]
> +static long wakeup_latency_gran(struct sched_entity *curr, struct sched_entity *se)
> +{
> +	long latency_offset = se->latency_offset;
> +
> +	/*
> +	 * A negative latency offset means that the sched_entity has latency
> +	 * requirement that needs to be evaluated versus other entity.
> +	 * Otherwise, use the latency weight to evaluate how much scheduling
> +	 * delay is acceptable by se.
> +	 */
> +	if ((se->latency_offset < 0) || (curr->latency_offset < 0))
Maybe use latency_offset < 0 directly?
BTW, is it the policy that requires the user to provide a negative
latency nice so as to tell the kernel to compare between two tasks?
Maybe I missed the scenario, I'm thinking of the reason why we used
" || " rather than " && " above. To be more specific, why not comparing
se and curr only when they both have high requirement on latency(negative)?

The benefit of using "||" I'm thinking of is that, if se->latency_offset < 0
and curr->latency_offset > 0, the latency_offset would be even smaller than
se->latency_offset, which will make the preemption easier. And vice verse.

thanks,
Chenyu
> +		latency_offset -= curr->latency_offset;
> +
> +	return latency_offset;
> +}