From patchwork Mon Oct 2 13:33:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tip-bot2 for Thomas Gleixner X-Patchwork-Id: 147327 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1479248vqb; Mon, 2 Oct 2023 07:52:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGRWxZAsP4xCWvZ5u+mZRTBQKQnWPit7FMsO8JtwkSROflawB0ElKeFF9IMZm4d723tAIul X-Received: by 2002:a17:90a:2f61:b0:279:13c3:6b21 with SMTP id s88-20020a17090a2f6100b0027913c36b21mr9316975pjd.9.1696258325427; Mon, 02 Oct 2023 07:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696258325; cv=none; d=google.com; s=arc-20160816; b=mYX9foFznPQcjp1l9uqe/o0MBp8qULcak4BhyMyAWXLSRDdVti+y4rLm7vRsXvkalF aZZe8ArVojnkyMoHQG/IE7mEV2VQ6LCAL3IhbUP5vMP9mIfBW/hLe4V3e3+9+B8tWa9g eeQ7xPxCFPEuS+JMzPfGxSpEzmFNIzeOT1WA2iuOEpyCRwsMSvDm+K4GVl4o7HS2GA1n HBa3UP3s1aInrlvfsthlUauk3HNEZB07qZSHdn5Rjj2ZfKQklyuoC6phweg/8uAzQnr9 40kbW1ADqZFAlLEZb9MDzKDH4uC1owtnYabf9vdP3I5kkP/HgGGaM+XV4gkctguzzBJU w8mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=Z4vR6z7FcgztoBF309slRuSBwJPiM/3Isa9tBEl+Gr0=; fh=LcOZopNn7gm+JFHHAZk0tCihMQOZoWWYJXDCojcFWBU=; b=T5i5ja9Amlcyt/8cSnU5/E5VSzDPW8Qnw7z3FcW83QXqdsbpKRpM77NbEYwuMjkNCI YCj9J/Ev4RvDTvanhebOs0F1OX65n8uqoSbEGz2Mxkh6ZgqNCnQ6Ti/0TSbXLM9nobzb jI2WwIBNsqsNv+bgw6xqZwlfgdwnlvdhSxKP/M8ROfU9e/V6I+WKbm9//u4cP0Y0D+Qu v2gTog95sePWhUa9Wi3+3ZoLbaslFUiyMWfMWoXGAGFhpa9kPDJHjo+PWeQQxuj7ixax c2LzuT3S/f1roXdt6L1u+DxL7Mw9qQReUBpKA6ROx6VHgIBlrAS7xRem+KOpdeiyXSzn r5JA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=mOJ+wbg3; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id kk8-20020a17090b4a0800b002791e9b60f9si8097999pjb.48.2023.10.02.07.52.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 07:52:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=mOJ+wbg3; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 5F2ED80293D9; Mon, 2 Oct 2023 06:34:14 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237441AbjJBNeF (ORCPT + 18 others); Mon, 2 Oct 2023 09:34:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237182AbjJBNeC (ORCPT ); Mon, 2 Oct 2023 09:34:02 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D18EAD; Mon, 2 Oct 2023 06:33:59 -0700 (PDT) Date: Mon, 02 Oct 2023 13:33:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1696253637; h=from:from:sender:sender:reply-to: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=Z4vR6z7FcgztoBF309slRuSBwJPiM/3Isa9tBEl+Gr0=; b=mOJ+wbg3OBccfwNWEYBZbcCYMawV5RuSyL8mWFnE1C5W6UDEsuoJRmSyxbm/E+AceRWRDp wCSDTc+zv1QLsin+RWZZ8WQ/tKfRaTiMvikuyjvGT+u+Kfhc7OQ56FPn0BcwDpRXKr9Muz ONIcZq6wdMrA1BryC7pZ17DtQPKA6H4jzhyMo/I+89cCZEywhQl4fM2f2QxN5J6/EFDMO9 fRym3PgiRlQXYF8rF1ZL6ZeC7Ks5NMhP8VE0C07vWMvtyNk3MyS5Ya2JOn4ny6n744bnLG GCBnlSKedpvvDjsuQaveqDHMUGbfvztbvsQ7M7sADrIPC2rSYA+2HCfh8GqHzw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1696253637; h=from:from:sender:sender:reply-to: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=Z4vR6z7FcgztoBF309slRuSBwJPiM/3Isa9tBEl+Gr0=; b=brH8OE/sPQOW3CTRM+SLFYrHvoA67gjNTKNsBjd4giBKIO3CwBns8VMBzg2FORkMAwJqn2 1OkfYOjoxIbLtkBg== From: "tip-bot2 for Cyril Hrubis" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] sched/rt/docs: Use 'real-time' instead of 'realtime' Cc: Cyril Hrubis , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231002115553.3007-4-chrubis@suse.cz> References: <20231002115553.3007-4-chrubis@suse.cz> MIME-Version: 1.0 Message-ID: <169625363643.3135.2547495399686514705.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails 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_PASS 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-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 02 Oct 2023 06:34:14 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778655769799078467 X-GMAIL-MSGID: 1778655769799078467 The following commit has been merged into the sched/core branch of tip: Commit-ID: 83494dc51033506eb60c5e11a335461b2dc42111 Gitweb: https://git.kernel.org/tip/83494dc51033506eb60c5e11a335461b2dc42111 Author: Cyril Hrubis AuthorDate: Mon, 02 Oct 2023 13:55:53 +02:00 Committer: Ingo Molnar CommitterDate: Mon, 02 Oct 2023 15:17:14 +02:00 sched/rt/docs: Use 'real-time' instead of 'realtime' Standardize on a single variant. Signed-off-by: Cyril Hrubis Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20231002115553.3007-4-chrubis@suse.cz --- Documentation/scheduler/sched-rt-group.rst | 34 ++++++++++----------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/Documentation/scheduler/sched-rt-group.rst b/Documentation/scheduler/sched-rt-group.rst index a16bee8..d685609 100644 --- a/Documentation/scheduler/sched-rt-group.rst +++ b/Documentation/scheduler/sched-rt-group.rst @@ -39,10 +39,10 @@ Most notable: 1.1 The problem --------------- -Realtime scheduling is all about determinism, a group has to be able to rely on +Real-time scheduling is all about determinism, a group has to be able to rely on the amount of bandwidth (eg. CPU time) being constant. In order to schedule -multiple groups of realtime tasks, each group must be assigned a fixed portion -of the CPU time available. Without a minimum guarantee a realtime group can +multiple groups of real-time tasks, each group must be assigned a fixed portion +of the CPU time available. Without a minimum guarantee a real-time group can obviously fall short. A fuzzy upper limit is of no use since it cannot be relied upon. Which leaves us with just the single fixed portion. @@ -50,14 +50,14 @@ relied upon. Which leaves us with just the single fixed portion. ---------------- CPU time is divided by means of specifying how much time can be spent running -in a given period. We allocate this "run time" for each realtime group which -the other realtime groups will not be permitted to use. +in a given period. We allocate this "run time" for each real-time group which +the other real-time groups will not be permitted to use. -Any time not allocated to a realtime group will be used to run normal priority +Any time not allocated to a real-time group will be used to run normal priority tasks (SCHED_OTHER). Any allocated run time not used will also be picked up by SCHED_OTHER. -Let's consider an example: a frame fixed realtime renderer must deliver 25 +Let's consider an example: a frame fixed real-time renderer must deliver 25 frames a second, which yields a period of 0.04s per frame. Now say it will also have to play some music and respond to input, leaving it with around 80% CPU time dedicated for the graphics. We can then give this group a run time of 0.8 @@ -70,7 +70,7 @@ needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s = of 0.00015s. The remaining CPU time will be used for user input and other tasks. Because -realtime tasks have explicitly allocated the CPU time they need to perform +real-time tasks have explicitly allocated the CPU time they need to perform their tasks, buffer underruns in the graphics or audio can be eliminated. NOTE: the above example is not fully implemented yet. We still @@ -90,12 +90,12 @@ The system wide settings are configured under the /proc virtual file system: The scheduling period that is equivalent to 100% CPU bandwidth. /proc/sys/kernel/sched_rt_runtime_us: - A global limit on how much time realtime scheduling may use. This is always + A global limit on how much time real-time scheduling may use. This is always less or equal to the period_us, as it denotes the time allocated from the - period_us for the realtime tasks. Even without CONFIG_RT_GROUP_SCHED enabled, - this will limit time reserved to realtime processes. With + period_us for the real-time tasks. Even without CONFIG_RT_GROUP_SCHED enabled, + this will limit time reserved to real-time processes. With CONFIG_RT_GROUP_SCHED=y it signifies the total bandwidth available to all - realtime groups. + real-time groups. * Time is specified in us because the interface is s32. This gives an operating range from 1us to about 35 minutes. @@ -110,7 +110,7 @@ The system wide settings are configured under the /proc virtual file system: The default values for sched_rt_period_us (1000000 or 1s) and sched_rt_runtime_us (950000 or 0.95s). This gives 0.05s to be used by SCHED_OTHER (non-RT tasks). These defaults were chosen so that a run-away -realtime tasks will not lock up the machine but leave a little time to recover +real-time tasks will not lock up the machine but leave a little time to recover it. By setting runtime to -1 you'd get the old behaviour back. By default all bandwidth is assigned to the root group and new groups get the @@ -118,10 +118,10 @@ period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you want to assign bandwidth to another group, reduce the root group's bandwidth and assign some or all of the difference to another group. -Realtime group scheduling means you have to assign a portion of total CPU -bandwidth to the group before it will accept realtime tasks. Therefore you will -not be able to run realtime tasks as any user other than root until you have -done that, even if the user has the rights to run processes with realtime +Real-time group scheduling means you have to assign a portion of total CPU +bandwidth to the group before it will accept real-time tasks. Therefore you will +not be able to run real-time tasks as any user other than root until you have +done that, even if the user has the rights to run processes with real-time priority!