From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936927AbdLSBDV (ORCPT ); Mon, 18 Dec 2017 20:03:21 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:46809 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935486AbdLSBDR (ORCPT ); Mon, 18 Dec 2017 20:03:17 -0500 X-Google-Smtp-Source: ACJfBotJ588f3vvpwg9+kNen35c0skH3ECxBlX72izZ/moGUNUFo2rKWaLDNgKAyDuWw4FL1ThmjNw== Date: Tue, 19 Dec 2017 10:03:11 +0900 From: Sergey Senozhatsky To: Steven Rostedt Cc: Petr Mladek , Sergey Senozhatsky , Tejun Heo , Sergey Senozhatsky , Jan Kara , Andrew Morton , Peter Zijlstra , Rafael Wysocki , Pavel Machek , Tetsuo Handa , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread Message-ID: <20171219010311.GB8892@jagdpanzerIV> References: <20171214221831.3ead0298@vmware.local.home> <20171215050607.GC11199@jagdpanzerIV> <20171215083151.cu3xbdgmxqkszwso@pathway.suse.cz> <20171215084236.GE468@jagdpanzerIV> <20171215090801.eulx4pg54p667ya5@pathway.suse.cz> <20171218093405.GA31274@jagdpanzerIV> <20171218133101.ri55uwivhc5xwg5y@pathway.suse.cz> <20171218133948.GD31274@jagdpanzerIV> <20171218141353.6shpvcwth34k6dsi@pathway.suse.cz> <20171218124613.1df152da@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171218124613.1df152da@gandalf.local.home> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (12/18/17 12:46), Steven Rostedt wrote: > On Mon, 18 Dec 2017 15:13:53 +0100 > Petr Mladek wrote: > > > One question is if we really want to rely on offloading in > > this case. What if this is printed to debug some stalled > > system. > > Correct, and this is what I call when debugging hard lockups, and I do > it from NMI. Which the new NMI code prevents all the data I want to > print to come out to console. > > I had to create a really huge buffer to print it. > > show_state_filter() is not a normal printk() call. It is used for > debugging. Not a very good example of issues that happen on production > systems. If anything, this should be disabled on a production system. > > Let's just add my patch (I'll respin it if it needs it), and send it > off into the wild. Let's see if there's still reports of issues, and > then come back to solutions. Because, really, I'm still not convinced > that there's anything out there that needs much more "fixing" of > printk(). ... do you guys read my emails? which part of the traces I have provided suggests that there is any improvement? -ss