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 531CFC54EE9 for ; Fri, 16 Sep 2022 12:03:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1FFD8D0002; Fri, 16 Sep 2022 08:03:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CFBD8D0001; Fri, 16 Sep 2022 08:03:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C0128D0002; Fri, 16 Sep 2022 08:03:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7E2F08D0001 for ; Fri, 16 Sep 2022 08:03:01 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 58280140D40 for ; Fri, 16 Sep 2022 12:03:01 +0000 (UTC) X-FDA: 79917812562.19.8E809E6 Received: from r3-25.sinamail.sina.com.cn (r3-25.sinamail.sina.com.cn [202.108.3.25]) by imf23.hostedemail.com (Postfix) with ESMTP id 3B2111400CC for ; Fri, 16 Sep 2022 12:02:58 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([114.249.57.76]) by sina.com (172.16.97.23) with ESMTP id 632465A70001C769; Fri, 16 Sep 2022 20:01:45 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 36106754919527 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: Fri, 16 Sep 2022 20:02:45 +0800 Message-Id: <20220916120245.2951-1-hdanton@sina.com> In-Reply-To: <20220916080305.29574-6-vincent.guittot@linaro.org> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663329781; a=rsa-sha256; cv=none; b=bnzwjTaWK86R2nYllimTRD5xmniC3XMAie/CJTstaI3N77TgZ/PJVnTsOqXzoSO/U7QkCD eoI+07pXVFFCnnHtDrzgENlS60b8jh1D9183SEsqOOr6/g3V2Ok6MILLT6wZ2OGxrV2O7a EvOk3sRjXvbKXUEGSShfATsw3XTtF1c= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663329781; 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=xon8ycZj50NJKrDyMb7koYxykW6ZrBDFPB7A5hmHgWs=; b=Xd6E5C629Py0W+xRPWGjwm3PgSnXXoaX4vqT/8HDZ6F0UCx8AC20+Qua/031jCWiuhhEFF eYtLdxzPS/ZDVgBj626rUb/IU0xM051cFPQ15pbZCVFM44B3fBx0eJhbhYV3f959UYTf9V jPZZbWAlALofDOfX6Dwotw0j10cra60= X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3B2111400CC Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.25 as permitted sender) smtp.mailfrom=hdanton@sina.com X-Stat-Signature: wbhefcyia6kboxijgt6pwj53ibwj5grx X-HE-Tag: 1663329778-320572 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: 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; + + if (delta_exec < granu) + return; + delta = curr->vruntime - se->vruntime; if (delta < 0)