From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A053CC54EE9 for ; Tue, 20 Sep 2022 11:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AB22940008; Tue, 20 Sep 2022 07:32:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05B44940007; Tue, 20 Sep 2022 07:32:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6461940008; Tue, 20 Sep 2022 07:32:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D393F940007 for ; Tue, 20 Sep 2022 07:32:53 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9CC7840D1A for ; Tue, 20 Sep 2022 11:32:53 +0000 (UTC) X-FDA: 79932251826.05.B7EDC48 Received: from r3-20.sinamail.sina.com.cn (r3-20.sinamail.sina.com.cn [202.108.3.20]) by imf02.hostedemail.com (Postfix) with ESMTP id AE5CE8000D for ; Tue, 20 Sep 2022 11:32:50 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.56.57]) by sina.com (172.16.97.35) with ESMTP id 6329A48C0002717A; Tue, 20 Sep 2022 19:31:26 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 41760715073739 From: Hillf Danton To: Vincent Guittot Cc: peterz@infradead.org, mgorman@suse.de, valentin.schneider@arm.com, parth@linux.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 5/8] sched/fair: Take into account latency priority at wakeup Date: Tue, 20 Sep 2022 19:32:38 +0800 Message-Id: <20220920113238.1176-1-hdanton@sina.com> In-Reply-To: References: <20220916080305.29574-6-vincent.guittot@linaro.org> <20220916120245.2951-1-hdanton@sina.com> <20220917225819.817-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.20 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663673572; a=rsa-sha256; cv=none; b=AABsw1HLH1hC2M0dOSDO9f9b1PJpyZIyOaU+lwtZJCyBjoQXYjl/zXVDy8c9G0Se7kdZja Y83AL+b2ZIH883phpy7NI/TblvkJEsEu8Jj0gFzw7n2hPkTB+YfQgDgiW2WYDBqjPWvsKF AC0eOP9vKJ82lq/OYHhrXHE+k8y5SVk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663673572; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MaStslxxZ0LFGZ3/7HT7KR1QKOSohqWjfcqkMq13VdY=; b=dshA5BcxnccfgPWxnXpoxi3mjsGxRpYYh71iu0y4IXPQ3eTScxs7VwCq8/MOT/PpN/dlj4 UN+T2N/EVLDgg6qHhsLBjFH3elukNPt4rOLq1C1XfYNi6091lqtbnT+SBV808nvTnIe7DG DAowypMUcCJkwgovtVMr+gOuEwFt28g= X-Stat-Signature: nqj19san5hkz8ti1zcmms587fwtftr7n X-Rspamd-Queue-Id: AE5CE8000D Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.20 as permitted sender) smtp.mailfrom=hdanton@sina.com X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1663673570-704748 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 18 Sep 2022 12:46:00 +0200 Vincent Guittot wrote: > On Sun, 18 Sept 2022 at 00:58, Hillf Danton wrote: > > > > On 16 Sep 2022 15:36:53 +0200 Vincent Guittot wrote: > > > > > > Hi Hillf, > > > > > > On Fri, 16 Sept 2022 at 14:03, Hillf Danton wrote: > > > > > > > > Hello Vincent > > > > > > > > On 16 Sep 2022 10:03:02 +0200 Vincent Guittot wrote: > > > > > > > > > > @@ -4606,6 +4608,7 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) > > > > > > > > > > se = __pick_first_entity(cfs_rq); > > > > > delta = curr->vruntime - se->vruntime; > > > > > + delta -= wakeup_latency_gran(curr, se); > > > > > > > > > > if (delta < 0) > > > > > return; > > > > > > > > What is derived from the latency nice you added is the runtime granulaity > > > > which has a role in preempting the current task. > > > > > > > > Given the same defination of latency nice as the nice, the runtime granularity > > > > can be computed without introducing the latency nice. > > > > > > > > Only for thoughts now. > > > > > > > > Hillf > > > > > > > > +++ b/kernel/sched/fair.c > > > > @@ -4569,7 +4569,7 @@ dequeue_entity(struct cfs_rq *cfs_rq, st > > > > static void > > > > check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) > > > > { > > > > - unsigned long ideal_runtime, delta_exec; > > > > + unsigned long ideal_runtime, delta_exec, granu; > > > > struct sched_entity *se; > > > > s64 delta; > > > > > > > > @@ -4594,6 +4594,14 @@ check_preempt_tick(struct cfs_rq *cfs_rq > > > > return; > > > > > > > > se = __pick_first_entity(cfs_rq); > > > > + > > > > + granu = sysctl_sched_min_granularity + > > > > + (ideal_runtime - sysctl_sched_min_granularity) * > > > > + (se->latency_nice + 20) / LATENCY_NICE_WIDTH; > > > > > > There is no latency_nice field in se but a latency_offset instead > > > > > > Also at this step, we are sure that curr has run at least > > > sysctl_sched_min_granularity and we want now to compare curr vruntime > > > with first se's one. We take the latency offset into account to make > > > sure we will not preempt curr too early > > > > > > > + > > > > + if (delta_exec < granu) > > > > + return; > > > > + > > > > delta = curr->vruntime - se->vruntime; > > > > > > > > if (delta < 0) > > return; > > > > if (delta > ideal_runtime) > > resched_curr(rq_of(cfs_rq)); > > > > After another look, curr is not preempted without the gap in vruntime > > between curr and the first entity growing more than ideal runtime, while > > Curr can be preempted as it has run more than the ideal time (1st > test). This one is to make sure that the diff does not become too > large. Here we reuse the same comparison as wakeup to make sure that a > newly curr will get a chance to run its ideal time after having > preempted at wakeup the previous current IIUC it would take two checks to preempt correctly - diff in vruntime is checked first to avoid preempting too early, then it is checked again with latency_offset taken into account to avoid preempting too late. +++ b/kernel/sched/fair.c @@ -4571,7 +4571,7 @@ check_preempt_tick(struct cfs_rq *cfs_rq { unsigned long ideal_runtime, delta_exec; struct sched_entity *se; - s64 delta; + s64 delta, d2; ideal_runtime = sched_slice(cfs_rq, curr); delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime; @@ -4595,11 +4595,9 @@ check_preempt_tick(struct cfs_rq *cfs_rq se = __pick_first_entity(cfs_rq); delta = curr->vruntime - se->vruntime; + d2 = delta - wakeup_latency_gran(curr, se); - if (delta < 0) - return; - - if (delta > ideal_runtime) + if (delta > ideal_runtime || d2 > ideal_runtime) resched_curr(rq_of(cfs_rq)); }