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 21DF7C25B67 for ; Thu, 26 Oct 2023 17:26:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 844CA8D0003; Thu, 26 Oct 2023 13:26:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CDAF8D0001; Thu, 26 Oct 2023 13:26:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66F118D0003; Thu, 26 Oct 2023 13:26:50 -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 5594A8D0001 for ; Thu, 26 Oct 2023 13:26:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0D64E120555 for ; Thu, 26 Oct 2023 17:26:50 +0000 (UTC) X-FDA: 81388292580.05.6466B8F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf16.hostedemail.com (Postfix) with ESMTP id 23836180016 for ; Thu, 26 Oct 2023 17:26:46 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of "SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698341207; a=rsa-sha256; cv=none; b=FifHt4KIch898jxzTCZz5rcuijncD4Lx+BeQl1r9Mjr5OaCvnqVBSDimw3H2oIvV2RPOZg mgVYWjRyFj04QJHyjFKznt/AcQL8YH1afvutC1PMjk7dkEkNqA7dS0Fp4z1adyDVvmu9Rs 9Brr3MLUerSV+4jOrJd1aZf39r5Czxw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of "SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=xBQK=GI=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698341207; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FYIgs6OofRUOZZvmzUbEpgQ2pTgSn/KEqE+wMlCXPaU=; b=62hZ2Po2ROCEKX0OJj5ukNTyn6vn3CwLwZvbzwZjROTbVHjPpHvDu48U1nvSKBMfW1HHPQ MWkivd0peduAG4aRPS+N32QoW/ZmS3GXT/cjsxqmbW2ZLagq1e7sPuwNo80VxsKkHFlc3p aV/pS7Z/3eIkX8M911D6PV1ggH+OLhU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 54EC0B837BE; Thu, 26 Oct 2023 17:26:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EA58C433C9; Thu, 26 Oct 2023 17:26:41 +0000 (UTC) Date: Thu, 26 Oct 2023 13:26:39 -0400 From: Steven Rostedt To: Daniel Bristot de Oliveira Cc: Peter Zijlstra , Mateusz Guzik , Mathieu Desnoyers , LKML , Thomas Gleixner , Ankur Arora , Linus Torvalds , linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Youssef Esmat , Vineeth Pillai , Suleiman Souhlal , Ingo Molnar Subject: Re: [POC][RFC][PATCH] sched: Extended Scheduler Time Slice Message-ID: <20231026132639.538a0741@gandalf.local.home> In-Reply-To: <82b0104f-1f05-44b0-9e95-57beecd541c8@kernel.org> References: <20231025054219.1acaa3dd@gandalf.local.home> <20231025102952.GG37471@noisy.programming.kicks-ass.net> <20231025085434.35d5f9e0@gandalf.local.home> <20231025135545.GG31201@noisy.programming.kicks-ass.net> <20231025103105.5ec64b89@gandalf.local.home> <884e4603-4d29-41ae-8715-a070c43482c4@efficios.com> <20231025162435.ibhdktcshhzltr3r@f> <20231025131731.48461873@gandalf.local.home> <20231026085414.GL31411@noisy.programming.kicks-ass.net> <20231026094035.213e3744@gandalf.local.home> <20231026114927.46145fe6@gandalf.local.home> <82b0104f-1f05-44b0-9e95-57beecd541c8@kernel.org> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 23836180016 X-Stat-Signature: k4md838cohibedh9816jbmugdjm5o47u X-HE-Tag: 1698341206-568071 X-HE-Meta: U2FsdGVkX18ZhCcyNQmZ5CkPMTLeHsNHEbb+Cezh+DQofGyHHXBJn3dreRRWq88LwzDynRWlRlVRN4VXuDdXKOvFd+YNV/9OUXkR+HzYKtikQ23AAwoAPWHu6VFytRpS7J8gt/6b/kn7dPksunK+ebKsaXxmFKrRMTkp3iJMlRELN3V+S9CPApyTol7P0gpvV6RYvubgoutrBjLAf4sOiNYCou679i/WqqnwW2/lqd/3Uw4fCsezADVtxW+Zfx+lSO1mxG8TdeVmh/5R9UpRXGM+J5LtIUe7lL4PyPiegABCCBIhYFL3g8+z4dTHVwKV7XkArCu7/eDGNqXH4U9whL8q5hcCgwsUioTXzMdczHBP0XIc1vtzKoUsomOEJ+QvCbXrXnt4W8eAGiWafV38oq55Ui6uD3lViwX8CEzr5eWgkPdyxwmXje4c/QPlNNc1u5k8OqFnazz5IZ7GkH+9NcMAlfeV7aR3bckoIuX6UDvu9aXUYHySqytR8BBZ2MR+nx0IKs3PeG7lc2r64ISwlwNXx6pSp15Qu0PK5bDlCBul4p1dr5LKmj2jVUAd1Hi6TpTiOK48yVhiAo1LCXr5j9FSjC49Hr2/kqjJgQsaKKOTpfODbegRG1Xsqvw8FyLhARpRmt4nebzLZ3pClGteCbzJUFXmbGOQI/b6M+rXjKilbanMTJMDYAlPDbPL3lwaCeDN3xYfvVvsPvj2SHj7Q2RclcdZjyqo8iMm+DfogQvW10+uxEmAuDqZ3nrGnFpg+4kFu7MsxxHWkJCYeHV3qnq3M8UywhdSbBcyhNl4eFaQokJpckdXmhkfjnUCAna/cxtx9CTxa4XgHC49zsBgt/T/wnZVzqeSfwmvl6xdf6ujDKDc9xCeU2QSruo3AfqbnwJ8s7nB11Ab4x6WQHqhdxHE4DtYlHxPwTxom3Ny+Kw8rYl0gjtrx7IM/NsTkXvfIusUhlPrKv2tt5h07l+ FZCa8A1x u4QPwiepZZblfOadKoSRB8p8vXpEYhIExofYyli8oFTM21RbVQL74V0MwJnCMBWZ6RKCWVfh8hXndelj/KPB+zv8sz1KZTe5ncGfY9/deK6daULFp1hHl7eMl0BLUpginPplkypdS77wyZwW+2pEN0Aka1GLniIgI8hbxeo9zUeLSesAnbbe9ualQhkcuTn7WUd71SUW+0AbMGapdOncsl25XVMWciZ5J+LyAsJjE5pkMjvXnTF8UGGQENwtmE367rzhrn5ir0wc8UCjguolNxEw0ujrkunj72WiGUliMy7KOVzkbgrN8Om5n+g== 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: List-Subscribe: List-Unsubscribe: On Thu, 26 Oct 2023 18:31:56 +0200 Daniel Bristot de Oliveira wrote: > > This feature is a performance boost only, and has nothing to do with > > "correctness". That's because it has that arbitrary time where it can run a > > little more. It's more like the difference between having something in > > cache and a cache miss. This would cause many academics to quit and find a > > job in sales if they had to prove the correctness of an algorithm that gave > > you a boost for some random amount of time. The idea here is to help with > > performance. If it exists, great, your application will likely perform > > better. If it doesn't, no big deal, you may just have to deal with longer > > wait times on critical sections. > > terminologies, terminologies.... those academic people :-) I hope this doesn't cause you to quit and switch to a career in sales! > > I think that this can also be seen as an extension of the non-preemptive > mode to the user space, but... not entirely, it is a ceiling to the > [ higher than fair/lower than RT ] prior? Well, it's just an extended time slice of SCHED_OTHER (up to 1 ms on 1000Hz to 4 ms on 250Hz). But if an RT or DL task were to wake up it would preempt it immediately. This feature is at the whims of the kernel implementation that provides no guarantees. It's just a hint from user space asking the kernel if it can have a little more time to get out of a critical section where the time slice ended unfortunately while the task was in a critical section. The kernel is allowed to deny the request. > > and it is not global. It is partitioned: once the section starts, it stays > there, being preempted by RT/DL? Basically yes. Looking at the v6.6-rc4 kernel (which is where I started from), the base time slice is 3ms. # cat /sys/kernel/debug/sched/base_slice_ns 3000000 Note, when I upped this to 6ms, the benefits of this patch did drop. That makes total sense because that would drop the number of times the critical section would be preempted. Basically, it does somewhat the same thing by extending all time slices. With this feature enabled, if the schedule slice ends on a critical section that has this special bit set, the kernel will give up to 1 more ms (1000 HZ) to get out of that section. It will also tell user space that it is running on extended time by setting bit 1 (0x2). When user space leaves the critical section, it should check that bit and if it is set call any system call which the kernel will then call schedule. In my example, I just used sched_yield(), but it would work with gettid() as well. Sure, user space can ignore that bit from the kernel and continue, but when that 1ms is up, the kernel will preempt that task with prejudice, regardless if its in a critical section or not. It's in the task's best interest to make that system call when it knows it's the best time to do so (not within a critical section). If it does not, it risks being preempted within a critical section. Not to mention that the EEVDF scheduler will lower it's eligibility for the next round. -- Steve