From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751810AbdIEOWU (ORCPT ); Tue, 5 Sep 2017 10:22:20 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:37774 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751646AbdIEOWO (ORCPT ); Tue, 5 Sep 2017 10:22:14 -0400 X-Google-Smtp-Source: ADKCNb5CeZaRPWzoArihH5B+6P7EmoNjn2y8oMNgTFX/aEAPc9yBiRB9otYX1dC/hrP5Xrlu4YOANg== Date: Tue, 5 Sep 2017 23:18:03 +0900 From: Sergey Senozhatsky To: Tetsuo Handa Cc: pmladek@suse.com, sergey.senozhatsky.work@gmail.com, joe@perches.com, rostedt@goodmis.org, torvalds@linux-foundation.org, pavel@ucw.cz, sergey.senozhatsky@gmail.com, jack@suse.cz, akpm@linux-foundation.org, jslaby@suse.com, andi@lisas.de, linux-kernel@vger.kernel.org Subject: Re: printk: what is going on with additional newlines? Message-ID: <20170905141803.GA502@tigerII.localdomain> References: <1504060296.2786.8.camel@perches.com> <20170830024703.GA17175@jagdpanzerIV.localdomain> <20170905094452.GE8741@pathway.suse.cz> <20170905095900.GC2066@jagdpanzerIV.localdomain> <20170905122154.GG8741@pathway.suse.cz> <201709052135.BJH73984.QLMOJFFOtFOSHV@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201709052135.BJH73984.QLMOJFFOtFOSHV@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (09/05/17 21:35), Tetsuo Handa wrote: [..] > > Well, what do you think about the extra printed information? > > For example: > > > > message > > > > It looks straightforward to me. These information > > might be helpful on its own. So, it might be a > > win-win solution. > > Yes, if buffering multiple lines will not be implemented, I do want > printk context identifier field for each line. I think > part will be something like TASK#pid (if outside interrupt) or > CPU#cpunum/#irqlevel (if inside interrupt). well, depending on what's your aim. it's not always printk() that causes troubles, but console_unlock(). which is busy because of printk()-s. and those are not necessarily running on the same CPU. so if you want to have a full picture (don't know what for) then you need to log both vprintk_emit() and console_unlock() sides. vprintk_emit() side requires changes to `struct printk_log', console_unlock() does not - you can just sprintf() the required data to `text' buffer. for example, I do the following on my PC boxes to keep track the behaviour of printk kthread offloading. --- diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index a4e3f84ef365..ac1fd606d6c5 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2493,15 +2493,16 @@ void console_unlock(void) seen_seq = log_next_seq; } + len = sprintf(text, "{%s/%d/%d}", current->comm, + smp_processor_id(), do_cond_resched); + if (console_seq < log_first_seq) { - len = sprintf(text, "** %u printk messages dropped ** ", + len += sprintf(text + len, "** %u printk messages dropped ** ", (unsigned)(log_first_seq - console_seq)); /* messages are gone, move to first one */ console_seq = log_first_seq; console_idx = log_first_idx; - } else { - len = 0; } skip: if (did_offload || console_seq == log_next_seq)