hi, Peter thanks for your reply! On 2015年08月11日 20:00, Peter Hurley wrote: > On 08/11/2015 07:23 AM, Pan Xinhui wrote: >> From: Pan Xinhui <xinhuix....@intel.com> >> >> printk can be called in any context, It's very useful to output debug >> info. >> >> But it might cause very bad issues on some special cases. For example, >> some driver hit errors, and it dumps many messages like reg values, etc. >> >> Sometimes, printk is called when irqs disabled. This is OKay if there is >> a few messages. But What would happen if many messages outputted by other >> drivers at same time. >> >> Here is the scenario. >> CPUA CPUB >> local_irq_save(flags); >> printk() >> while(..) { --> console_unlock >> printk(...); >> //hundreds or thousands loops >> } //all messages flushed out to consoles >> local_irq_restore(flags); >> >> printk runs on CPUA just store the messages in the buf and return. >> printk runs on CPUB(who owns the console_sem lock) would take the duty >> to flush all messages to consoles. It would take a long time to flush >> messages out, IOW, irq would be disabled for a long time. Such case is >> too bad. We hit many interrupt related panics, for example, cpu did not >> respond to IPI. >> >> Here is the solution, if we detect such case above, try to rebalance it. >> Let CPUA take the duty to flush messages to consoles. >> >> The idea is simple, but the implementation is a little difficult. >> Introduce many help functions to fix it. > > Please describe the rebalance state machine/message passing in detail. > > Regards, > Peter Hurley > yes, I should describe it more detailedly. Sorry for that. I will send out V2.
thanks xinhui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/