From patchwork Mon Mar 6 13:25:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Zijlstra X-Patchwork-Id: 6169 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1892337wrd; Mon, 6 Mar 2023 07:07:40 -0800 (PST) X-Google-Smtp-Source: AK7set9dicF3IEHXG66q0Bzey3tZM/WdS8zBTgtcg03dvEngsmTJ6ag2yuADTbf4cZiOaeefxa3i X-Received: by 2002:a17:902:74c4:b0:19e:6b50:e220 with SMTP id f4-20020a17090274c400b0019e6b50e220mr9841059plt.53.1678115260293; Mon, 06 Mar 2023 07:07:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678115260; cv=none; d=google.com; s=arc-20160816; b=xpqj5pYkpeAmoa55Ovg88iOO5Uif/wBl13xbhiFy6W11SjPnmGTn7m6ZZQGNowMXr0 F9QU1QnzM2uODp+AbSEaOzcuN0o3i6g0qrbEZ4st1szs7ObMIOCTa1IUVfufV+2kmly+ W4ZYTe/RC5UvMyFb9s5insQ86F4pKE97hMELmi1Eq8IwhLQPMFvKB+0FmftK2DnCO8HP jeNQhQVhrcczAhqAuYKV6TKz6a0esFhaLWqd/JsSD8uklZupIcVSjuEMihN70MZOHTz4 weNwEup+p55sjqcqc9d51djFuiME+t1BWo2fL71d9mSUR3prl1/8t0/5weNtT2f7NhJY XnmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:cc:to:from:date:user-agent:message-id :dkim-signature; bh=Xz7dL2tcnPT6ww6dXBhPnkI2dUM8QaQFf+4VBLsgKss=; b=vS+HUdbq/gTH8ZCD9qCTaSg2kH0E/cCz0oADhsBlQNcTS2tbQGB4F1Rre1P4yUHwPz BY1lOpJngN3MXB6AzfWyLqLHunRs10Yt9+U1DtKkdZJ5GKLEYEhxwrEG3xrr8R/PcJZq imxF5dP/B8aEfaBgoDhvySz69gA7BUe/WuBT8KqT6a1PCRzy1u7pPC+UrU51M3v0zBmD QFXofcXcfWuU6PVMRhu5WVjB3HVZWk4Lx0exSMyEwVogQ0lzG1oQ5y9tuevS+7DVbSNp a23DO+i9IHuV7b2Ev0sIUTBWoXNe6aFBK/JZzhOdVnAQUn7L6uNOW5hV56QEBNHQhXFZ 67tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=WbbkGE3k; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x4-20020a170902ec8400b0019cb63d38e3si10311849plg.589.2023.03.06.07.07.27; Mon, 06 Mar 2023 07:07:40 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=WbbkGE3k; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231283AbjCFOVK (ORCPT + 99 others); Mon, 6 Mar 2023 09:21:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231617AbjCFOUV (ORCPT ); Mon, 6 Mar 2023 09:20:21 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DB768A61 for ; Mon, 6 Mar 2023 06:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Subject:Cc:To:From:Date:Message-ID: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To:References; bh=Xz7dL2tcnPT6ww6dXBhPnkI2dUM8QaQFf+4VBLsgKss=; b=WbbkGE3kA9CEMDoY7iWLv8LRxj 8VLWzwhdYPKhqDA2EeHvBBgyKGhtaeqRnQr+yZ8E6ILGKV950+Jh81aPZm7ATs20i7+hQHCyhHWLU IL45M6i0+82G35n+5LT0/ZVIw7rWAMNSurUpRpuwpCmebPZQOkfqL8u2TXk+HDfeoZOutFPh0jil3 6Ax+40Ffr05BlpJmlMEgn9j+J6/QgyXLVL1tbFNstaZUmzWJhtusDEnx78r1FigM68tMldvAaBu/7 NQFvxTZqCMEupJgAK33qmR6q7AJ/FWoRHYtEekIo4/UDg/hSaGBurYrX8TL93ildpK87KsgiIgGz7 6ftM4S3w==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZBe5-005P2M-Iu; Mon, 06 Mar 2023 14:16:58 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 08881300137; Mon, 6 Mar 2023 15:16:55 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 0) id E55AB2130D7A2; Mon, 6 Mar 2023 15:16:54 +0100 (CET) Message-ID: <20230306132521.968182689@infradead.org> User-Agent: quilt/0.66 Date: Mon, 06 Mar 2023 14:25:21 +0100 From: Peter Zijlstra To: mingo@kernel.org, vincent.guittot@linaro.org Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, corbet@lwn.net, qyousef@layalina.io, chris.hyser@oracle.com, patrick.bellasi@matbug.net, pjt@google.com, pavel@ucw.cz, qperret@google.com, tim.c.chen@linux.intel.com, joshdon@google.com, timj@gnu.org, kprateek.nayak@amd.com, yu.c.chen@intel.com, youssefesmat@chromium.org, joel@joelfernandes.org Subject: [PATCH 00/10] sched: EEVDF using latency-nice X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759631387107430563?= X-GMAIL-MSGID: =?utf-8?q?1759631387107430563?= Hi! Ever since looking at the latency-nice patches, I've wondered if EEVDF would not make more sense, and I did point Vincent at some older patches I had for that (which is here his augmented rbtree thing comes from). Also, since I really dislike the dual tree, I also figured we could dynamically switch between an augmented tree and not (and while I have code for that, that's not included in this posting because with the current results I don't think we actually need this). Anyway, since I'm somewhat under the weather, I spend last week desperately trying to connect a small cluster of neurons in defiance of the snot overlord and bring back the EEVDF patches from the dark crypts where they'd been gathering cobwebs for the past 13 odd years. By friday they worked well enough, and this morning (because obviously I forgot the weekend is ideal to run benchmarks) I ran a bunch of hackbenck, netperf, tbench and sysbench -- there's a bunch of wins and losses, but nothing that indicates a total fail. ( in fact, some of the schbench results seem to indicate EEVDF schedules a lot more consistent than CFS and has a bunch of latency wins ) ( hackbench also doesn't show the augmented tree and generally more expensive pick to be a loss, in fact it shows a slight win here ) hackbech load + cyclictest --policy other results: EEVDF CFS # Min Latencies: 00053 LNICE(19) # Avg Latencies: 04350 # Max Latencies: 76019 # Min Latencies: 00052 00053 LNICE(0) # Avg Latencies: 00690 00687 # Max Latencies: 14145 13913 # Min Latencies: 00019 LNICE(-19) # Avg Latencies: 00261 # Max Latencies: 05642 The nice -19 numbers aren't as pretty as Vincent's, but at the end I was going cross-eyed from staring at tree prints and I just couldn't figure out where it was going side-ways. There's definitely more benchmarking/tweaking to be done (0-day already reported a stress-ng loss), but if we can pull this off we can delete a whole much of icky heuristics code. EEVDF is a much better defined policy than what we currently have. Tested-by: Shrikanth Hegde