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 52380C77B70 for ; Tue, 11 Apr 2023 13:33:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 872EE6B0078; Tue, 11 Apr 2023 09:33:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 823246B007B; Tue, 11 Apr 2023 09:33:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7115E900004; Tue, 11 Apr 2023 09:33:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 60E646B0078 for ; Tue, 11 Apr 2023 09:33:52 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 22CB8160D46 for ; Tue, 11 Apr 2023 13:33:52 +0000 (UTC) X-FDA: 80669203104.09.31D622A Received: from r3-21.sinamail.sina.com.cn (r3-21.sinamail.sina.com.cn [202.108.3.21]) by imf28.hostedemail.com (Postfix) with ESMTP id 0CABCC001A for ; Tue, 11 Apr 2023 13:33:48 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.21 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=1681220030; 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=6jBmiwLKHqISwP8vap6oiL+hWj8yqcJNUVx/ehaLYU4=; b=UZ11A1/y94D7qat30pAQqizVxYd5hODLDCl0361phSG/HOmdXxLo91/zmwV1POIBonPwNg X1z1e6G5Yr1P4MePUcyPdOVnD6qXRAEerup6QbvYms3oB18e8ZS58inm7SxuAhb/bK3PSA cELqU8rE6WWcndnCJQABP5tELVDTmm4= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.21 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681220030; a=rsa-sha256; cv=none; b=nhSK+Y0tnms9iBhlqz5PisxHwxvjk/ewVhsrAxrmNJ7ihgGRHJOKck4T9yCtiBdlFf27Jy 4iqqRf5VNNUNe9OCxdslXdmjW4FQLr/kAEPVllYklCSd8l0LCOIaq7psa2bz9SJ/QvjuRx DwCyZMIEQJc1++UwUzDI5pbOPOSTjqY= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.59.75]) by sina.com (172.16.97.32) with ESMTP id 6435617700014888; Tue, 11 Apr 2023 21:32:41 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 730053628870 From: Hillf Danton To: Mike Galbraith Cc: Peter Zijlstra , mingo@kernel.org, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de, bristot@redhat.com, corbet@lwn.net, kprateek.nayak@amd.com, youssefesmat@chromium.org, joel@joelfernandes.org Subject: Re: [PATCH 00/17] sched: EEVDF using latency-nice Date: Tue, 11 Apr 2023 21:33:33 +0800 Message-Id: <20230411133333.1790-1-hdanton@sina.com> In-Reply-To: References: <20230328092622.062917921@infradead.org> <20230410082307.1327-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 0CABCC001A X-Stat-Signature: 76ais8sz83x4fua1su8qbkxbpkkkcja8 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1681220028-128419 X-HE-Meta: U2FsdGVkX18RDg2CRdozRD+ld9lOaByrX7r/A/02jIUJxkPlWheAskWcbJrd74t3P3VYXThG2jIYMacW+m3++XHJDpfVp5LGghMj1fyHb5ng7pfPdT+acs3CA3kXY79V97VJx1HL/wtDwlBi0/UCciiZ1Z66NbiYgu07KVSzHNYF5JfLyLkPDR+JvgBkq/TXBO+7nIF1y6dkVQwivefQkMd2Xy4Boq+NQTCeUeOXxmo2HGTk30y6tgqDugLw4ZLY4De5psIaZyoP53djiwG3sEKJLOXB6uKr2IaNlgIEzMcFVFrbfBDqaV2yZr9ctL52RwQYZR56w29fgoIf7gmu+NGCyvOC2Ub333XPewcNLXIfHJS2p7uClvrWvPEnvfLfO4c1GsTr8AyiZszu6kY9v/CZTW548V2sTXdNaP0YKRk7B8J8A2VPsBkcFbQcdWjtIcxMHc+43SAhJp0K6VDq7Veh4zn2rFoyoN/YXLI6Uwx5Oba+98qRDWXUHdzmTyhYT1HMxBoOnrabZnNnxcrTvTsu/2pgFO0rRl22ha9kbgAwIdsWB/i874PzpXm5CzcV9odT3nA8xRCTr5HbdmSWO0VTeYVlQLfajt7o7rCeltaC5O9T2/maekv3V6rgzCSojv0EENt3AonN+M8fmzNxLFz+lGA7fAbGaDpG7VWIfWqWwZ8OXc8GtsAi/1SpBjA2Ig/TgXD3TDhd814xyQkePfNLfgeC9CBpexAt6b/l3id6ck+iKwoage91GeTCuyT0oyRzLjZ6vDY2X/fOCx06+bDMlSBAJTFcpyIDvvysfdCI/OkGVz6NvsR9eWUy50b6IlEkpNAJJar4xaxqcM8h1Lg3PVUw8jFkQcVmiIz4f9TPSrYjl8+e45QVM/RZXGtt3nZ0TZ2uxSC5Cv0eWCCCgigbRLyHZI8OKuNKjJVtfaivLMSSKcKQfmvMGESAnDnX1pfRJbl8G5Ba1zu3srU FQ1eLoGh 4YYFT3cfrdguMVzy++w5DO+iZ2EjV6PxaQ/f2oMI2ONxIY91PznAMFMH5iCsE+ABzcV0Mpd1ekHd5BSflGRVlMIXQ2CFtZn8JIdZa 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 Tue, 11 Apr 2023 12:15:41 +0200 Mike Galbraith > On Mon, 2023-04-10 at 16:23 +0800, Hillf Danton wrote: > > > > In order to only narrow down the poor performance reported, make a tradeoff > > between runtime and latency simply by restoring sysctl_sched_min_granularity > > at tick preempt, given the known order on the runqueue. > > Tick preemption isn't the primary contributor to the scheduling delta, > it's wakeup preemption. If you look at the perf summaries of 5 minute > recordings on my little 8 rq box below, you'll see that the delta is > more than twice what a 250Hz tick could inflict. You could also just > turn off WAKEUP_PREEMPTION and watch the delta instantly peg negative. > > Anyway... > > Given we know preemption is markedly up, and as always a source of pain > (as well as gain), perhaps we can try to tamp it down a little without > inserting old constraints into the shiny new scheduler. > > The dirt simple tweak below puts a dent in the sting by merely sticking > with whatever decision EEVDF last made until it itself invalidates that > decision. It still selects via the same math, just does so the tiniest > bit less frenetically. > > --- > kernel/sched/fair.c | 3 +++ > kernel/sched/features.h | 6 ++++++ > 2 files changed, 9 insertions(+) > > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -950,6 +950,9 @@ static struct sched_entity *pick_eevdf(s > if (curr && (!curr->on_rq || !entity_eligible(cfs_rq, curr))) > curr =3D NULL; > > + if (sched_feat(GENTLE_EEVDF) && curr) > + return curr; > + This is rather aggressive, given latency-10 curr and latency-0 candidate at tick hit for instance. And along your direction a mild change is postpone the preempt wakeup to the next tick. +++ b/kernel/sched/fair.c @@ -7932,8 +7932,6 @@ static void check_preempt_wakeup(struct return; cfs_rq = cfs_rq_of(se); - update_curr(cfs_rq); - /* * XXX pick_eevdf(cfs_rq) != se ? */