From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937623AbdLSEhG (ORCPT ); Mon, 18 Dec 2017 23:37:06 -0500 Received: from mail-pl0-f66.google.com ([209.85.160.66]:39225 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934761AbdLSEhD (ORCPT ); Mon, 18 Dec 2017 23:37:03 -0500 X-Google-Smtp-Source: ACJfBotPSm8f/Bt8l2E9wAYg6R3nuP386DxyzAaDNWJ9q9VpdySDOS1a71xMXhAGUasYSgZoAL8k1g== Date: Tue, 19 Dec 2017 13:36:58 +0900 From: Sergey Senozhatsky To: Steven Rostedt , Petr Mladek Cc: 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: <20171219043658.GD17164@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: > > 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. [..] > show_state_filter() is not a normal printk() call. It is used for > debugging. just for the record. a side note. you guys somehow made spectacularly off-target conclusions from the traces I have provided and decided NOT to concentrate on demonstrated behavioural patterns, but on, perhaps, process' names (I really should have renamed i_do_printks to DONALD_TRUMP ;) ) and on how those printk lines got into the logbuf. like if it mattered. [seriously, why?]. the point was not in show_state_filter()... the point was - preemption and things that hand off does. but somehow filling up logbuf when console_sem owner is preempted is unrealistic if printks are coming from task A under normal conditions; and it is a completely different story when the same task A fills up logbuf from OOM while console_sem owner is preempted. the end result is the same in both cases: it's not task A that is going to flush logbuf. it's some other task that will have to do it, possibly being in atomic context. anyway, anyway. -ss