Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933650AbbHLBiZ (ORCPT ); Tue, 11 Aug 2015 21:38:25 -0400 Received: from mga09.intel.com ([134.134.136.24]:31040 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933628AbbHLBiY (ORCPT ); Tue, 11 Aug 2015 21:38:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,657,1432623600"; d="scan'208";a="766877420" Message-ID: <55CAA2FF.8050800@intel.com> Date: Wed, 12 Aug 2015 09:35:59 +0800 From: Pan Xinhui User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Peter Hurley CC: "linux-kernel@vger.kernel.org" , Andrew Morton , pmladek@suse.cz, rostedt@goodmis.org, Tejun Heo , Greg Kroah-Hartman , Joe Perches , hch@lst.de, viro@zeniv.linux.org.uk, Vasily Averin Subject: Re: [PATCH] printk: rebalance printk References: <55C9DB15.2070800@intel.com> <55C9E3F4.3050504@hurleysoftware.com> In-Reply-To: <55C9E3F4.3050504@hurleysoftware.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1944 Lines: 54 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 >> >> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/