Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp1775996img; Wed, 27 Feb 2019 05:18:16 -0800 (PST) X-Google-Smtp-Source: AHgI3IaJZxYT2TZ7Bqzdy3a773K8/810WJ+turDE9KE7XfamsFLbnWcJ+Uk65tp/UEGx6qyowsye X-Received: by 2002:a17:902:8c95:: with SMTP id t21mr2095642plo.300.1551273496059; Wed, 27 Feb 2019 05:18:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551273496; cv=none; d=google.com; s=arc-20160816; b=LSpj7+fNX9UqEcXfhNWMG8qNaj/EW+xEi2KMmlkdT7LBA/iszzRzK5ppYFFUI/oebS jzDRxOVVVgMNoDBQaI1lY7Q/5VhE1F9W7XltW0RZBhMUGS0tdZmbDLnW0A5pqK6VWEzb oRnKSMNnKkwIspqRODqUQX/2P/MhkeKAPvkfX3sv6KGngwDkHtnWpDdFepMgRCrH3nRS qk7TdZRgrSzsq96Fw1wXF91H22o7INgszbLfiMlh0AT5t6VYmMBFiF1HC+T5cSOAr4YB JqZWHMqTT5B+9yAsWZ5HGtiOsTrfVSw5ELhZib1z7VWcA2YDetmZzhyli4vXUAsTBdHB vHpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+pVLz2Ew73nM51+PXFdK85znWPRvk4Ayfjo2HwncxUo=; b=m6WUjKaU2hyqNuyZmo6+RGwaWSP8WZgJFLGDwnLT0rXfiwSAtbld4KN4sumVEERz6U k3N9KWTVt2WN6F96iqxIxZnk43CbsvfA1yJUPBuGHspX7MRYLXiamWQcNdJ8kxCeD3sb 9s7pVHzt1oBln4v6VeQsbmFmQJyYCumrjbQd/1Jl1s7ehNOBjuTKGu6iP5NzctcXhVXK li00/HitZGNpJVuVpdJ1ohNN+PZuSAA8yPrsoyTbHbBxj1/mlT+cmYddcC7pI0r6KZ+i VxVkS+3ZQqbxldfPl7dbQdTkCa0++2xgbQoFu9q9bF4R0NlvBG+zxaPEohD0JzLLBphK rXow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z21si15081849plo.317.2019.02.27.05.18.00; Wed, 27 Feb 2019 05:18:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730073AbfB0NM7 (ORCPT + 99 others); Wed, 27 Feb 2019 08:12:59 -0500 Received: from mx2.suse.de ([195.135.220.15]:42366 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726122AbfB0NM6 (ORCPT ); Wed, 27 Feb 2019 08:12:58 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 696C8AEB0; Wed, 27 Feb 2019 13:12:56 +0000 (UTC) Date: Wed, 27 Feb 2019 14:12:53 +0100 From: Petr Mladek To: John Ogness Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Sergey Senozhatsky , Steven Rostedt , Daniel Wang , Andrew Morton , Linus Torvalds , Greg Kroah-Hartman , Alan Cox , Jiri Slaby , Peter Feiner , linux-serial@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC PATCH v1 15/25] printk: print history for new consoles Message-ID: <20190227131253.kdfmz4gmrufusihu@pathway.suse.cz> References: <20190212143003.48446-1-john.ogness@linutronix.de> <20190212143003.48446-16-john.ogness@linutronix.de> <20190226145837.wl54fr7rn2ii5oxc@pathway.suse.cz> <87o96yziau.fsf@linutronix.de> <20190227090249.fzigc7r237emlg6k@pathway.suse.cz> <874l8pft0y.fsf@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874l8pft0y.fsf@linutronix.de> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2019-02-27 11:02:53, John Ogness wrote: > On 2019-02-27, Petr Mladek wrote: > > I mean that your patch does the reply on a very hidden location. > > Right. I understand that and I agree. > > > Regarding the per-console kthread. It would make sense if > > we stop handling all consoles synchronously. For example, > > when we push messages to fast consoles immediately and > > offload the work for slow consoles. > > My per-console kthread suggestion relating to fast consoles is so that > some consoles (such as netconsole, which is quite fast) could drop less > messages than a slow console (such as uart). OK, it was not clear from the context. > > Anyway, we first need to make the offload reliable enough. > > It is not acceptable to always offload all messages. > > We have been there last few years. We must keep a high > > chance to see the messages. Any warning might be important > > when it causes the system to die. Nobody knows what message > > is such an important. > > You seem to be missing the point of the series. It _is_ acceptable to > offload all messages because they are being offloaded to non-emergency > consoles. If messages are lost, it sucks (and the appropriate "dropped" > messages are sent), but it isn't critical. Once we can agree to this > point, printk becomes so much easier to work with. > > Emergency consoles exist for handling important messages. They will not > drop messages. They are synchronous and immediate. We might start thinking about this only when the most common consoles support the emergency mode. This patchset implemented it only for serial consoles that are often very slow. It is contradicting the above statement about fast consoles. Also the emergency messages from different CPUs are synchronized. This slows down all affected CPUs. They are serialized and blocked by the speed of the consoles. It was the reason to handle all pending messages only by the current owner. I am sure that it would cause regressions. Not to say that the synchronization is done using an unfair lock. One CPU can simply get starved by others for non-predictable time. This is why ticket spinlocks were invented. You might argue that the amount of emergency messages should be small but see below. > >> It is not necessary. It is desired. Why should _any_ task be punished > >> with console writing? That is what the printk kthread is for. > > > > I do not know about any acceptable solution without punishing > > the tasks. But we might find a better compromise between the > > punishment and reliability. > > I do not want printk to compromise. That compromise is part of the > problem. Let's partition printk to important and non-important so that > we can optimize both. _That_ is the heart of this series. No, this is just another compromise. Let's look at it from another side. The important and non-important messages already existed. The split was done by console_loglevel. The emergency level just adds one more category (show, show later, ignore). It allows more fine grained setting but it does not remove the compromise. People would still need to choose which messages should be seen reliably and which might get lost. And the problem will be still the same. The more messages will be printed reliably the more delayed might get printk() callers. It might prevent softlockups but only at the cost that all parallel writers are blocked by waiting for the console. Also note that printk configuration already is too complicated. See the four numbers in /proc/sys/kernel/printk. Many people would have troubles to set them reasonably even with description. Fifth number would only make it worse. And it is even more complicated because people are inconsistent with using the log levels, see https://lkml.kernel.org/r/20180619115726.3098-1-hdegoede@redhat.com It is a lost fight. People always need to see messages from the code that they work on. If we make it harder to see some levels, people will just start using levels that are not filtered. This is why I suggest to split the work on the ring buffer and consoles. The new ring buffer might be a clear win. While the console handling is really complicated. But I still think that we might and should do better even in the consoles. Best Regards, Petr