Messages in this thread |  | | From | Thomas Gleixner <> | Subject | Re: [PATCH] kernel: irq: Some words replce with better alternatives in the file timings.c | Date | Fri, 05 Feb 2021 19:43:14 +0100 |
| |
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
|  |