David Rientjes wrote:
On Fri, 18 Feb 2011, Mike Travis wrote:
Reduce the length for time zero messages by only printing "[0] ".
v2: updated to apply to x86-tip
Signed-off-by: Mike Travis <travis@xxxxxxx>
Reviewed-by: Jack Steiner <steiner@xxxxxxx>
Reviewed-by: Robin Holt <holt@xxxxxxx>
---
kernel/printk.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -735,9 +735,14 @@ static inline int printk_emit_time(void)
unsigned long microsec_rem;
t = cpu_clock(printk_cpu);
- microsec_rem = do_div(t, 1000000000) / 1000;
- tlen = sprintf(tbuf, "[%5lu.%06lu] ", (unsigned long)t, microsec_rem);
-
+ if (likely(t)) {
+ microsec_rem = do_div(t, 1000000000) / 1000;
+ tlen = sprintf(tbuf, "[%5lu.%06lu] ",
+ (unsigned long)t, microsec_rem);
The definition of microsec_rem can become local to this clause.
Ok.
+ } else {
+ /* reduce byte count in log when time is zero */
+ tlen = sprintf(tbuf, "[0] ");
If we know the padding when cpu_clock() is non-zero, then why not make
sure the kernel log is aligned properly by using the same padding here?
I'm not sure I understand what you are asking. The whole point of this
exercise is to remove bytes from the early log buffer so it does not
overflow. What would you like me to change?
+ }
for (tp = tbuf; tp < tbuf + tlen; tp++)
emit_log_char(*tp);
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
