Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp226434imj; Wed, 13 Feb 2019 07:21:39 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib7qq5Bv9wyaABv0qCl1txW8LhxSiAFgY2QwWR8u5Th59S411HmhFAsQluzIZDoPcfixR4Q X-Received: by 2002:a17:902:8f98:: with SMTP id z24mr1063378plo.40.1550071299872; Wed, 13 Feb 2019 07:21:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550071299; cv=none; d=google.com; s=arc-20160816; b=WfdU4qDN880iudtv7/y5EovOTRtD1WKfXJJil6OkBTo1YRpCCBnp/ZxXPcGKctVNUD quZVIlK0nB+AaYli4unENWHp+OyFDh5K6AB6y6fUf+l4nEkux0BCLiI2W2UYwGQo9aCf N1qGiTRAjXtF6ENa2jVthg7nEanhJChibEn3JZCDJL5msPsb7ef6dktTubjKlDpKizc9 HnCG7gIYTSZiB7ICgbPd68RVH2A7rg6WPiDVAs8iKVg1Z8TfLVmxGjCiTxuooUJs0Lhu VnZKBfShuagR+aAZI7cPsUV/lPMPtLu7KznWWx8AbrLO5iVBm/QmpjmeI2b49z8sLGEN Ik3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=RbaTKY4IgUa1SxZH2eHpjsn3d+i/PVZaOqOM5iafqhc=; b=QD/Dq7iXd3koFd/2VAeozXq6f/VRpbdEp4Cf9tynFCuD5M9oZ4Pz9z7rX2j2ApidO5 GfgnPjgFZEwbPWjaryq+hqH9MQN2zrlq+MvKCuB2tnmk9zJMynCoIhF19Lx0XmsJxULw 4/KzujSjrn9cw+7AdZUeBsuiLkx42r+LqHbBsvDa0dX3RecXnnzPyRcP3+rXvSPSyvdF hLjjHde8CZI+C8fZI/BADC26z/wnmfL17wS89MrM64LSf6aqqb9c+LLyhEDNjcq3oU00 S0YVr7LAUYdNUZ++bqquFbH8kmPwRDl4WXaneSaVdTbw49BHX4HfCBq924ujVdWdroqM kLQA== 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 j14si13645325pgg.44.2019.02.13.07.21.22; Wed, 13 Feb 2019 07:21:39 -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 S2390798AbfBMOnX (ORCPT + 99 others); Wed, 13 Feb 2019 09:43:23 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:46691 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728867AbfBMOnW (ORCPT ); Wed, 13 Feb 2019 09:43:22 -0500 Received: from localhost ([127.0.0.1] helo=vostro.local) by Galois.linutronix.de with esmtp (Exim 4.80) (envelope-from ) id 1gtvkk-0003ln-CI; Wed, 13 Feb 2019 15:43:10 +0100 From: John Ogness To: Sergey Senozhatsky Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Petr Mladek , 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 00/25] printk: new implementation References: <20190212143003.48446-1-john.ogness@linutronix.de> <20190213025520.GA5803@jagdpanzerIV> Date: Wed, 13 Feb 2019 15:43:08 +0100 In-Reply-To: <20190213025520.GA5803@jagdpanzerIV> (Sergey Senozhatsky's message of "Wed, 13 Feb 2019 11:55:20 +0900") Message-ID: <874l9721hf.fsf@linutronix.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-02-13, Sergey Senozhatsky wrote: >> - A dedicated kernel thread is created for printing to all consoles in >> a fully preemptible context. > > How do you handle sysrq- printouts on systems which can't > schedule printk-kthread? If those sysrq printouts are at the emergency loglevel (which most are), then they are printed immediately to the emergency consoles. This has already proved useful for our own kernel debugging work. For example, currently sysrq-z for very large traces result in messages being dropped because of printk buffer overflows. But with the emergency console we always see the full trace buffer. Because you have already done so much work and experimentation with printk-kthreads, I feel like many of your comments are related to your kthread work in this area. Really the big design change I make with my printk-kthread is that it is only for non-critical messages. For anything critical, users should rely on an emergency console. John Ogness