Received-SPF: pass (google.com: domain of linux-kernel+bounces-177660-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 13 May 2024 09:58:12 -0400
From: Phil Auld <pauld@redhat.com>
To: Paul Sherwood <paul.sherwood@codethink.co.uk>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	bristot@redhat.com, vschneid@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/deadline: Fix grammar and typos in comments
Message-ID: <20240513135812.GA9998@lorien.usersys.redhat.com>
References: <20240511082644.44757-1-paul.sherwood@codethink.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240511082644.44757-1-paul.sherwood@codethink.co.uk>

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
> 
> 

--