* [PATCH] kernel: irq: Some words replce with better alternatives in the file timings.c
@ 2021-02-05 12:28 Bhaskar Chowdhury
2021-02-05 18:43 ` Thomas Gleixner
0 siblings, 1 reply; 3+ messages in thread
From: Bhaskar Chowdhury @ 2021-02-05 12:28 UTC (permalink / raw)
To: tglx, linux-kernel; +Cc: rdunlap, Bhaskar Chowdhury
Some spelling fixes and replace with other similar meaning words.
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
kernel/irq/timings.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/kernel/irq/timings.c b/kernel/irq/timings.c
index 773b6105c4ae..72f69e3b1e8d 100644
--- a/kernel/irq/timings.c
+++ b/kernel/irq/timings.c
@@ -478,21 +478,21 @@ static inline void irq_timings_store(int irq, struct irqt_stat *irqs, u64 ts)
/*
* The interval type is u64 in order to deal with the same
- * type in our computation, that prevent mindfuck issues with
+ * type in our computation, that prevent mind blowing issues with
* overflow, sign and division.
*/
interval = ts - old_ts;
/*
* The interrupt triggered more than one second apart, that
- * ends the sequence as predictible for our purpose. In this
+ * ends the sequence as predictable for our purpose. In this
* case, assume we have the beginning of a sequence and the
- * timestamp is the first value. As it is impossible to
+ * timestamps is the first value. As it is impossible to
* predict anything at this point, return.
*
- * Note the first timestamp of the sequence will always fall
+ * Note the first timestamps of the sequence will always fall
* in this test because the old_ts is zero. That is what we
- * want as we need another timestamp to compute an interval.
+ * want as we need another timestamps to compute an interval.
*/
if (interval >= NSEC_PER_SEC) {
irqs->count = 0;
@@ -523,7 +523,7 @@ static inline void irq_timings_store(int irq, struct irqt_stat *irqs, u64 ts)
* thus the count is reinitialized.
*
* The array of values **must** be browsed in the time direction, the
- * timestamp must increase between an element and the next one.
+ * timestamps must increase between an element and the next one.
*
* Returns a nanosec time based estimation of the earliest interrupt,
* U64_MAX otherwise.
@@ -556,7 +556,7 @@ u64 irq_timings_next_event(u64 now)
* type but with the cost of extra computation in the
* interrupt handler hot path. We choose efficiency.
*
- * Inject measured irq/timestamp to the pattern prediction
+ * Inject measured irq/timestamps to the pattern prediction
* model while decrementing the counter because we consume the
* data from our circular buffer.
*/
--
2.30.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] kernel: irq: Some words replce with better alternatives in the file timings.c
2021-02-05 12:28 [PATCH] kernel: irq: Some words replce with better alternatives in the file timings.c Bhaskar Chowdhury
@ 2021-02-05 18:43 ` Thomas Gleixner
2021-02-06 0:30 ` Bhaskar Chowdhury
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Gleixner @ 2021-02-05 18:43 UTC (permalink / raw)
To: Bhaskar Chowdhury, linux-kernel; +Cc: rdunlap, Bhaskar Chowdhury
Bhaskar,
On Fri, Feb 05 2021 at 17:58, Bhaskar Chowdhury wrote:
The correct prefix for this file is:
genirq/timings:
which you can find via: git log kernel/irq/timings.c
Also if you send a patch with spelling fixes then you might take care
that your subject line does not contain spelling mistakes ...
> + * ends the sequence as predictable for our purpose. In this
> * case, assume we have the beginning of a sequence and the
> - * timestamp is the first value. As it is impossible to
> + * timestamps is the first value. As it is impossible to
timestamp is ... is correct
> * predict anything at this point, return.
> *
> - * Note the first timestamp of the sequence will always fall
> + * Note the first timestamps of the sequence will always fall
Same here
> * in this test because the old_ts is zero. That is what we
> - * want as we need another timestamp to compute an interval.
> + * want as we need another timestamps to compute an interval.
And here.
> */
> if (interval >= NSEC_PER_SEC) {
> irqs->count = 0;
> @@ -523,7 +523,7 @@ static inline void irq_timings_store(int irq, struct irqt_stat *irqs, u64 ts)
> * thus the count is reinitialized.
> *
> * The array of values **must** be browsed in the time direction, the
> - * timestamp must increase between an element and the next one.
> + * timestamps must increase between an element and the next one.
No 's' either.
> *
> * Returns a nanosec time based estimation of the earliest interrupt,
> * U64_MAX otherwise.
> @@ -556,7 +556,7 @@ u64 irq_timings_next_event(u64 now)
> * type but with the cost of extra computation in the
> * interrupt handler hot path. We choose efficiency.
> *
> - * Inject measured irq/timestamp to the pattern prediction
> + * Inject measured irq/timestamps to the pattern prediction
This one needs the 's', yes.
> * model while decrementing the counter because we consume the
> * data from our circular buffer.
> */
Thanks,
tglx
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] kernel: irq: Some words replce with better alternatives in the file timings.c
2021-02-05 18:43 ` Thomas Gleixner
@ 2021-02-06 0:30 ` Bhaskar Chowdhury
0 siblings, 0 replies; 3+ messages in thread
From: Bhaskar Chowdhury @ 2021-02-06 0:30 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, rdunlap
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
On 19:43 Fri 05 Feb 2021, Thomas Gleixner wrote:
>Bhaskar,
>
>On Fri, Feb 05 2021 at 17:58, Bhaskar Chowdhury wrote:
>
>The correct prefix for this file is:
>
> genirq/timings:
>
>which you can find via: git log kernel/irq/timings.c
>
>Also if you send a patch with spelling fixes then you might take care
>that your subject line does not contain spelling mistakes ...
Whoops! good catch ....thanks, Tohomas!
>
>> + * ends the sequence as predictable for our purpose. In this
>> * case, assume we have the beginning of a sequence and the
>> - * timestamp is the first value. As it is impossible to
>> + * timestamps is the first value. As it is impossible to
>
>timestamp is ... is correct
>
>> * predict anything at this point, return.
>> *
>> - * Note the first timestamp of the sequence will always fall
>> + * Note the first timestamps of the sequence will always fall
>
>Same here
>
>> * in this test because the old_ts is zero. That is what we
>> - * want as we need another timestamp to compute an interval.
>> + * want as we need another timestamps to compute an interval.
>
>And here.
>
>> */
>> if (interval >= NSEC_PER_SEC) {
>> irqs->count = 0;
>> @@ -523,7 +523,7 @@ static inline void irq_timings_store(int irq, struct irqt_stat *irqs, u64 ts)
>> * thus the count is reinitialized.
>> *
>> * The array of values **must** be browsed in the time direction, the
>> - * timestamp must increase between an element and the next one.
>> + * timestamps must increase between an element and the next one.
>
>No 's' either.
>
>> *
>> * Returns a nanosec time based estimation of the earliest interrupt,
>> * U64_MAX otherwise.
>> @@ -556,7 +556,7 @@ u64 irq_timings_next_event(u64 now)
>> * type but with the cost of extra computation in the
>> * interrupt handler hot path. We choose efficiency.
>> *
>> - * Inject measured irq/timestamp to the pattern prediction
>> + * Inject measured irq/timestamps to the pattern prediction
>
>This one needs the 's', yes.
>
>> * model while decrementing the counter because we consume the
>> * data from our circular buffer.
>> */
>
Can we please forget that this attempt is ever exists :)
>Thanks,
>
> tglx
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-02-06 3:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-05 12:28 [PATCH] kernel: irq: Some words replce with better alternatives in the file timings.c Bhaskar Chowdhury
2021-02-05 18:43 ` Thomas Gleixner
2021-02-06 0:30 ` Bhaskar Chowdhury
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).