[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240511082644.44757-1-paul.sherwood@codethink.co.uk>
Date: Sat, 11 May 2024 09:26:44 +0100
From: Paul Sherwood <paul.sherwood@...ethink.co.uk>
To: mingo@...hat.com,
peterz@...radead.org,
juri.lelli@...hat.com,
vincent.guittot@...aro.org,
dietmar.eggemann@....com,
rostedt@...dmis.org,
bsegall@...gle.com,
mgorman@...e.de,
bristot@...hat.com,
vschneid@...hat.com,
linux-kernel@...r.kernel.org
Cc: Paul Sherwood <paul.sherwood@...ethink.co.uk>
Subject: [PATCH] sched/deadline: Fix grammar and typos in comments
- conjugate verb to match subject of sentence
- s/a entity/an entity/g
- s/this misbehave/this misbehaviour/
- a few typos
Signed-off-by: Paul Sherwood <paul.sherwood@...ethink.co.uk>
---
kernel/sched/deadline.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a04a436af8cc..e9334b11edde 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -4,9 +4,9 @@
*
* Earliest Deadline First (EDF) + Constant Bandwidth Server (CBS).
*
- * Tasks that periodically executes their instances for less than their
+ * Tasks that periodically execute their instances for less than their
* runtime won't miss any of their deadlines.
- * Tasks that are not periodic or sporadic or that tries to execute more
+ * Tasks that are not periodic or sporadic or that try to execute more
* than their reserved bandwidth will be slowed down (and may potentially
* miss some of their deadlines), and won't affect any other task.
*
@@ -816,16 +816,16 @@ static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
* exhausting its runtime.
*
* Here we are interested in making runtime overrun possible, but we do
- * not want a entity which is misbehaving to affect the scheduling of all
+ * not want an entity which is misbehaving to affect the scheduling of all
* other entities.
* Therefore, a budgeting strategy called Constant Bandwidth Server (CBS)
* is used, in order to confine each entity within its own bandwidth.
*
* This function deals exactly with that, and ensures that when the runtime
- * of a entity is replenished, its deadline is also postponed. That ensures
+ * of an entity is replenished, its deadline is also postponed. That ensures
* the overrunning entity can't interfere with other entity in the system and
- * can't make them miss their deadlines. Reasons why this kind of overruns
- * could happen are, typically, a entity voluntarily trying to overcome its
+ * can't make them miss their deadlines. Reasons why this kind of overrun
+ * could happen are, typically, an entity voluntarily trying to overcome its
* runtime, or it just underestimated it during sched_setattr().
*/
static void replenish_dl_entity(struct sched_dl_entity *dl_se)
@@ -860,7 +860,7 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se)
* At this point, the deadline really should be "in
* the future" with respect to rq->clock. If it's
* not, we are, for some reason, lagging too much!
- * Anyway, after having warn userspace abut that,
+ * Anyway, after having warned userspace about that,
* we still try to keep the things running by
* resetting the deadline and the budget of the
* entity.
@@ -896,8 +896,8 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se)
*
* IOW we can't recycle current parameters.
*
- * Notice that the bandwidth check is done against the deadline. For
- * task with deadline equal to period this is the same of using
+ * Notice that the bandwidth check is done against the deadline. For a
+ * task with deadline equal to period this is the same as using
* dl_period instead of dl_deadline in the equation above.
*/
static bool dl_entity_overflow(struct sched_dl_entity *dl_se, u64 t)
@@ -930,8 +930,8 @@ static bool dl_entity_overflow(struct sched_dl_entity *dl_se, u64 t)
}
/*
- * Revised wakeup rule [1]: For self-suspending tasks, rather then
- * re-initializing task's runtime and deadline, the revised wakeup
+ * Revised wakeup rule [1]: For self-suspending tasks, rather than
+ * re-initializing the task's runtime and deadline, the revised wakeup
* rule adjusts the task's runtime to avoid the task to overrun its
* density.
*
@@ -941,7 +941,7 @@ static bool dl_entity_overflow(struct sched_dl_entity *dl_se, u64 t)
* Therefore, runtime can be adjusted to:
* runtime = (dl_runtime / dl_deadline) * (deadline - t)
*
- * In such way that runtime will be equal to the maximum density
+ * This way the runtime will be equal to the maximum density
* the task can use without breaking any rule.
*
* [1] Luca Abeni, Giuseppe Lipari, and Juri Lelli. 2015. Constant
@@ -987,9 +987,9 @@ static inline bool dl_is_implicit(struct sched_dl_entity *dl_se)
* When the task is starting a new period, the Original CBS is used. In this
* case, the runtime is replenished and a new absolute deadline is set.
*
- * When a task is queued before the begin of the next period, using the
- * remaining runtime and deadline could make the entity to overflow, see
- * dl_entity_overflow() to find more about runtime overflow. When such case
+ * When a task is queued before the beginning of the next period, using the
+ * remaining runtime and deadline could make the entity overflow, see
+ * dl_entity_overflow() to find more about runtime overflow. When such a case
* is detected, the runtime and deadline need to be updated.
*
* If the task has an implicit deadline, i.e., deadline == period, the Original
@@ -1002,7 +1002,7 @@ static inline bool dl_is_implicit(struct sched_dl_entity *dl_se)
* runtime/deadline in a period. With deadline < period, the task would
* overrun the runtime/period allowed bandwidth, breaking the admission test.
*
- * In order to prevent this misbehave, the Revisited CBS is used for
+ * In order to prevent this misbehaviour, the Revisited CBS is used for
* constrained deadline tasks when a runtime overflow is detected. In the
* Revisited CBS, rather than replenishing & setting a new absolute deadline,
* the remaining runtime of the task is reduced to avoid runtime overflow.
--
2.33.0
Powered by blists - more mailing lists