Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp1920904imc; Tue, 12 Mar 2019 03:31:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqyLOhqv/ZPaG4dBljYTvsv4A1o4Pfi/E854sgiLl4eJQq0i2cicftDfgRjV4DQrE5wCM9bK X-Received: by 2002:a63:4826:: with SMTP id v38mr6293356pga.370.1552386662347; Tue, 12 Mar 2019 03:31:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552386662; cv=none; d=google.com; s=arc-20160816; b=V6CtmdJ14G9wz3RkwUUXHxXxsirpzoerBDIgtAd6oYxGTKumOiKMZZc3ZEbOUFyRgO 97cM6nXrQMzAUqGLeexDMz/S6T5cu7FigNEfVYLO+NMYRWrgUTb4yw+fu6K3GFA2I1/a 5PNCjNC1M1wrcSbVC4BGhYraH53LST6v47F2V0GeM78JXBzp3vk1W5fmbm7bGH0z6PyZ GT7f5wanxgjzrOcazhrHLDHaWR/lYle29VMkyI6Pm7K2f0EQ94Uyy6wvi6uTfh6/xdDC B33qWYUSsyFSylK+Jxxok2DIrLrourTCXzP2fKdLX8aHKgMYu3y3PVJdrch/3+q2dbd2 RV1g== 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=bSgoOhht1QG6hj6b9SeAnWsIOUqzB+Ni1mqQTrN7qoU=; b=scwoQVqbzruNLRYi6WSnQ1Ro+Vx+5t5UEzp9/GZ6N2cY87xdhlQUJOg6EXNhFj0a9j NTp/9TT4rC7rWMatcjIpxi2emLNbJ/TK0DEJRmRe7/aH+/iN1AZePin0ZcxOSpzE/P/0 fdieECJWAHiKaXDhKd1yrdB47puzJH3gxyJM4LhsgbQbm1+UMeoz3niauBPsXfYy70tN kJyl7betbNWUOGqSwOyfcuAqYeqvwPV6ErqlXjVADlxVAT4rkXhqTpAdXaVzTdAZEF9v 8OhLW3ReVoDtzuOzNKCctH0qJ68n8rs2ZZ2yYB9BmnH6nrlx8LRMlxt/FDE1GTB62K2S D7tA== 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 e1si7630276pgm.45.2019.03.12.03.30.46; Tue, 12 Mar 2019 03:31:02 -0700 (PDT) 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 S1726623AbfCLKaU (ORCPT + 99 others); Tue, 12 Mar 2019 06:30:20 -0400 Received: from mx2.suse.de ([195.135.220.15]:41642 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725873AbfCLKaU (ORCPT ); Tue, 12 Mar 2019 06:30:20 -0400 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 D69CCAEC2; Tue, 12 Mar 2019 10:30:17 +0000 (UTC) Date: Tue, 12 Mar 2019 11:30:17 +0100 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Peter Zijlstra , Steven Rostedt , Daniel Wang , Andrew Morton , Linus Torvalds , Greg Kroah-Hartman , Alan Cox , Jiri Slaby , Peter Feiner , linux-serial@vger.kernel.org Subject: Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread Message-ID: <20190312103017.rvdtoc3j34eayleb@pathway.suse.cz> References: <20190212143003.48446-1-john.ogness@linutronix.de> <20190212143003.48446-9-john.ogness@linutronix.de> <20190304073856.GA552@jagdpanzerIV> <20190304100044.GC21004@jagdpanzerIV> <20190304110703.GA960@tigerII.localdomain> <87o96p9gtx.fsf@linutronix.de> <20190307051530.GC4893@jagdpanzerIV> <87va0pznsq.fsf@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87va0pznsq.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 Mon 2019-03-11 11:51:49, John Ogness wrote: > On 2019-03-07, Sergey Senozhatsky wrote: > > I don't really understand the role of loglevel anymore. > > "what the kernel considers" is a configuration option of the > administrator. The administrator can increase the verbocity of the > console (loglevel) without having negative effects on the system > itself. Where do you get the confidence that atomic console will not slow down the system? Have you tried it on real life workload when debugging a real life bug? Some benchmarks might help. Well, it would be needed to trigger some messages from them and see how the different approaches affect the overall system performance. > Also, if the system were to suddenly crash, those crash messages > shouldn't be in jeopardy just because the verbocity of the console was > turned up. This expects that the error messages will be enough to discover and fix the problem. > You (and Petr) talk about that _all_ console printing is for > emergencies. That if an administrator sets the loglevel to 7 it is > because the pr_info messages are just as important as the pr_emerg. It might be true when the messages with higher level (more critical) are not enough to understand the situation. > And if that is indeed the intention of console printing and loglevel, then > why is asynchronous printk calls for console messages even allowed > today? IMO that isn't taking the importance of the message very > seriously. Because it was working pretty well in the past. The amount of messages is still growing (code complexity, more CPUs, more devices, ...). Our customers have started reporting softlockups "only" 7 years ago or so. We currently have two level handling of messages: + all messages can be seen from userspace + messages below console_loglevel can be seen on the console You are introducing one more level of handling: + critical messages are printed on the console directly even before the queued less critical ones The third level would be acceptable when: + atomic consoles are reliable enough + the code complexity is worth the gain IMHO, we mix too many things here: + log buffer implementation + console offload + direct console handling using atomic consoles I see the potential in all areas: + lock less ring buffer helps to avoid deadlocks, and extra log buffers + console offload prevents too long stalls (softlockups) + direct console handling might help to avoid deadlocks and might make the output more reliable. I think that we are on the same page here. But we must use an incremental approach. It is not acceptable to replace everything by a single patch. And it is not acceptable to break important functionality and implement alternative solution several patches later. Also no solution is as ideal as it is sometimes presented in this thread. Best Regards, Petr