Messages in this thread | | | Date | Fri, 30 Jun 2017 22:38:44 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread |
| |
On (06/30/17 15:16), Petr Mladek wrote: > Anyway, the handshake during offloading might be pretty > problematic. To be honest, I do not have much experience > with it. I have shared some my fears in the other mail[1]. > Jan Kara spent a lot of time on this and probably could > say more. > > Maybe, we could try to look into the throotling path. Slowing down > massive printk() callers looks necessary when things gets > out of control.
throttling, in some form, is already there. I think.
there is a printk_delay() function. which we can silently activate when things don't look cool anymore. and printk_delay() is already getting called on every vprintk_emit() entry. the question is -- how big should be our delay value, and... when do we need to activate printk_delay()?
when the distance between console_seq and log_next_seq... suggests that we will drop (overwrite) un-flushed messages sooner than console_seq reaches log_next_seq? so log_next_seq is closer to log_first_seq than console_seq to log_next_seq. or something like this... I'm a bit tired after a long week; need more time to think about it.
the same printk_delay() *may be* can be used in console_unlock(), to give potential new console_sem owner more time. just an idea.
> I wonder if I could add some counter into task_struct. > It might be configurable. I am not sure if people would > want this enabled on production systems where the level > of messages should be lower anyway.
-ss
| |