From: Pan Xinhui <xinhuix.pan@intel.com>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
pmladek@suse.cz, rostedt@goodmis.org, Tejun Heo <tj@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joe Perches <joe@perches.com>,
hch@lst.de, viro@zeniv.linux.org.uk,
Vasily Averin <vvs@virtuozzo.com>
Subject: Re: [PATCH] printk: rebalance printk
Date: Wed, 12 Aug 2015 09:35:59 +0800 [thread overview]
Message-ID: <55CAA2FF.8050800@intel.com> (raw)
In-Reply-To: <55C9E3F4.3050504@hurleysoftware.com>
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.pan@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
next prev parent reply other threads:[~2015-08-12 1:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 11:23 [PATCH] printk: rebalance printk Pan Xinhui
2015-08-11 11:34 ` Pan Xinhui
2015-08-11 12:00 ` Peter Hurley
2015-08-12 1:35 ` Pan Xinhui [this message]
2015-08-11 18:16 ` Greg Kroah-Hartman
2015-08-12 1:53 ` Pan Xinhui
2015-08-12 2:04 ` Greg Kroah-Hartman
2015-08-12 2:20 ` Pan Xinhui
2015-08-12 12:31 ` Peter Hurley
2015-08-13 2:16 ` Pan Xinhui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55CAA2FF.8050800@intel.com \
--to=xinhuix.pan@intel.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@hurleysoftware.com \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vvs@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox