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 C8A35ECAAA1 for ; Sat, 17 Sep 2022 22:58:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFA4680008; Sat, 17 Sep 2022 18:58:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA98680007; Sat, 17 Sep 2022 18:58:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A719B80008; Sat, 17 Sep 2022 18:58:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9530380007 for ; Sat, 17 Sep 2022 18:58:33 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 655751405AC for ; Sat, 17 Sep 2022 22:58:33 +0000 (UTC) X-FDA: 79923093306.03.49F4946 Received: from r3-25.sinamail.sina.com.cn (r3-25.sinamail.sina.com.cn [202.108.3.25]) by imf18.hostedemail.com (Postfix) with ESMTP id 567671C0002 for ; Sat, 17 Sep 2022 22:58:30 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.57.76]) by sina.com (172.16.97.23) with ESMTP id 632650CB00007550; Sat, 18 Sep 2022 06:57:16 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 95924254919395 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: Sun, 18 Sep 2022 06:58:19 +0800 Message-Id: <20220917225819.817-1-hdanton@sina.com> In-Reply-To: References: <20220916080305.29574-6-vincent.guittot@linaro.org> <20220916120245.2951-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663455513; a=rsa-sha256; cv=none; b=I+PaKvcC5tNc8bWD/PyoZSIKB0lX21zy+NV8n9hTSL22+psHWhENwqQk0SvX9KxKIZZNxC oi+TZD3uFUbJ6d6VyjZj/f+B4Dbg8+pXxznmFAaA/wobVEhLX+9gGXaF4VlyQ7BJZJ4Thp 7uATx5AJBm5U29Md0aozo/3wR2Seh+o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663455513; 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=UFnsozanF4D6daGxYMcaA/A2DeuojSoWDqpjDvLg8RI=; b=tFkIWM9O5jY7KsFwYZBYndADxtp6kIPHROICuEHdElFHtOfuwWqzK3hMugo443C8C7IBtg PRKBWzwOGOVSofkW/YTn72jW1Q5n0kZR1sNgDg3od7ECtHhbbeZSv64AmJfh981u4X1PcW 3N0ZIDvJYVmJiD6VFZdDubsRlzS5tpQ= X-Rspam-User: X-Stat-Signature: dioz19fcgi1uq715chffkjqfm1tf8xhb X-Rspamd-Queue-Id: 567671C0002 Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam04 X-HE-Tag: 1663455510-63324 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 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 with latency_offset, since the gap becomes larger, preempt happens later than ideal runtime thoughts IMO.