On (06/05/17 16:10), Sergey Senozhatsky wrote:
[..]
> > Notice the timestamp jump between [ 351.239144] and [ 389.308085].
>
> do you have a restrictive console loglevel and a ton of messages that
> were simply filtered out by console loglevel check? we still store those
> messages to the logbuf (for dmesg, etc.) and process them in console_unlock(),
> but don't print to the serial console. so, in other words,
>
> logbuf:
>
> timestamp T0 message M0 -- visible loglevel
> timestamp T1 message M1 -- suppressed loglevel
> ....
> timestamp T100 message M101 -- suppressed loglevel
> timestamp T101 message M102 -- visible loglevel
>
> on the serial console you'll see
>
> T0 M0
> T101 M102
>
> which might look like a spike in timestamps (while there weren't any).
> just a thought.
does it make any difference if you disable preemption in console_unlock()?
something like below... just curious...
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index a1aecf44ab07..25fe408cb994 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2204,6 +2204,8 @@ void console_unlock(void)
return;
}
+ preempt_disable();
+
for (;;) {
struct printk_log *msg;
size_t ext_len = 0;
@@ -2260,9 +2262,6 @@ void console_unlock(void)
call_console_drivers(ext_text, ext_len, text, len);
start_critical_timings();
printk_safe_exit_irqrestore(flags);
-
- if (do_cond_resched)
- cond_resched();
}
console_locked = 0;
@@ -2274,6 +2273,8 @@ void console_unlock(void)
up_console_sem();
+ preempt_enable();
+
/*
* Someone could have filled up the buffer again, so re-check if there's
* something to flush. In case we cannot trylock the console_sem again,
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
