[PATCH] sched/deadline: Fix grammar and typos in comments

[PATCH] sched/deadline: Fix grammar and typos in comments

[Paul Sherwood]

- 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@codethink.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

Re: [PATCH] sched/deadline: Fix grammar and typos in comments

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

On Sat, May 11, 2024 at 09:26:44AM +0100, Paul Sherwood wrote:
> - conjugate verb to match subject of sentence
> - s/a entity/an entity/g
> - s/this misbehave/this misbehaviour/
> - a few typos
> 

LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] sched/deadline: Fix grammar and typos in comments

[Phil Auld]

On Sat, May 11, 2024 at 09:26:44AM +0100 Paul Sherwood wrote:
> - conjugate verb to match subject of sentence
> - s/a entity/an entity/g
> - s/this misbehave/this misbehaviour/
> - a few typos
>
  - not starting all the lines of a commit message with "-", priceless.

Plus, you're just repeating what's in the actual patch.

Otherwise, these changes themselves look good to me.



Cheers,
Phil


> Signed-off-by: Paul Sherwood <paul.sherwood@codethink.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
> 
> 

-- 

Re: [PATCH] sched/deadline: Fix grammar and typos in comments

[Paul Sherwood]

On 2024-05-13 14:58, Phil Auld wrote:
> On Sat, May 11, 2024 at 09:26:44AM +0100 Paul Sherwood wrote:
>> - conjugate verb to match subject of sentence
>> - s/a entity/an entity/g
>> - s/this misbehave/this misbehaviour/
>> - a few typos
>> 
>   - not starting all the lines of a commit message with "-", priceless.
> 
> Plus, you're just repeating what's in the actual patch.
> 
> Otherwise, these changes themselves look good to me.

Thanks for the feedback - would you like me to re-submit without the 
bullet-points, or without the text entirely?

br
Paul

Re: [PATCH] sched/deadline: Fix grammar and typos in comments

[Phil Auld]

On Mon, May 13, 2024 at 04:19:10PM +0100 Paul Sherwood wrote:
> On 2024-05-13 14:58, Phil Auld wrote:
> > On Sat, May 11, 2024 at 09:26:44AM +0100 Paul Sherwood wrote:
> > > - conjugate verb to match subject of sentence
> > > - s/a entity/an entity/g
> > > - s/this misbehave/this misbehaviour/
> > > - a few typos
> > > 
> >   - not starting all the lines of a commit message with "-", priceless.
> > 
> > Plus, you're just repeating what's in the actual patch.
> > 
> > Otherwise, these changes themselves look good to me.
> 
> Thanks for the feedback - would you like me to re-submit without the
> bullet-points, or without the text entirely?
>

Personally I'd rather a sentence or two saying something like
"Fix some types and grammar issues in sched deadline comments."
Or something.  I know that's basically same as the title, but
that gets lost in the subject line, so maybe worded a little
differently? For this it probably doesn't need much but does
need something. 

I'm not the one to merge it though so I don't know if the
maintainer wanted to just fix it up at the time.   Just my
opinion...


For the changes themselves, fwiw,

Reviewed-by: Phil Auld <pauld@redhat.com>



Cheers,
Phil

> br
> Paul
> 

-- 
 

Re: [PATCH] sched/deadline: Fix grammar and typos in comments

[Daniel Bristot de Oliveira]

On 5/13/24 18:25, Phil Auld wrote:
> On Mon, May 13, 2024 at 04:19:10PM +0100 Paul Sherwood wrote:
>> On 2024-05-13 14:58, Phil Auld wrote:
>>> On Sat, May 11, 2024 at 09:26:44AM +0100 Paul Sherwood wrote:
>>>> - conjugate verb to match subject of sentence
>>>> - s/a entity/an entity/g
>>>> - s/this misbehave/this misbehaviour/
>>>> - a few typos
>>>>
>>>   - not starting all the lines of a commit message with "-", priceless.
>>>
>>> Plus, you're just repeating what's in the actual patch.
>>>
>>> Otherwise, these changes themselves look good to me.
>>
>> Thanks for the feedback - would you like me to re-submit without the
>> bullet-points, or without the text entirely?
>>
> 
> Personally I'd rather a sentence or two saying something like
> "Fix some types and grammar issues in sched deadline comments."
> Or something.  I know that's basically same as the title, but
> that gets lost in the subject line, so maybe worded a little
> differently? For this it probably doesn't need much but does
> need something. 

Yeah, I would say that a short sentence, then the bullet points, looks
better.

-- Daniel