Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3567689ybk; Tue, 19 May 2020 07:47:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwschKKmINoi1dbyPBXFNXHrWZ5TZTZ81A1kK0ou/2yFUzFC+L7APfh1AgwnVqnpJ76ADuI X-Received: by 2002:aa7:c401:: with SMTP id j1mr5977643edq.94.1589899651214; Tue, 19 May 2020 07:47:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589899651; cv=none; d=google.com; s=arc-20160816; b=K2UniWeA67pSp+yZ6vY7dK/xaA5HVW3eo6HubFkTAycQ0cpPlcL/Di2EHTNB10QCF0 v6+uya6vU8qUml3X2YuoUz48pnfuHH9dflXKku9+IwS66dXmuy7R5iKOYrGbzQJk8hqO dUoQecIt0z4ut2YiIpbzKpUTAb8Qca9piOx5zQyLnebHwWTmfmMvpwghvAl12ETXbUVG rXzZpGS7m9um62y12/JkHj3+g56C0VKfHFB+ulmOIYyqddjE0fpcgo2Co3YuWCO/ohN8 09GdaQ0MujTHH8rgEGfOldDv03GjZJJfBOEF0H81Jqep9Km3VemjB9vXhULKu96eRC7D u3Xw== 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=ocOjUUxTUbJ7dwi7eikTFhk2NeSsKzaUvHZ1HZ9WdlY=; b=Xuon0zfQw7vehzlbIpl9o53hoUku60T++cKOYDdaPgnfPNRx7LRuD3/vcVTbIiLcCk UCyuh3Ru6Os86+bjKVV4wLYYZ83d7QeoVx9NGoZuqtmH3seUgZVdaGINyH9dN4SvRLUf m7BcUPi8KefhbHNECjQaB4AaV4ZdGe9d6J5zn27z/+M8KUfOiCcPXBePegbN00FbKTsO /kOFceTHOpwx6fyYeKV/Jx5qIFF8qqdKyMIXW3ONU8TJEqLpUTWTnB2+AOPLHVFAZs4d IUr803XCSNOdUra15rGrkjHyo/RbgcHUsO54pnuTUjvl1RKdSB/jssLmi182/1IByAeO oKCQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x17si9074339edi.409.2020.05.19.07.47.06; Tue, 19 May 2020 07:47:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728953AbgESOoA (ORCPT + 99 others); Tue, 19 May 2020 10:44:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:44196 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726504AbgESOn7 (ORCPT ); Tue, 19 May 2020 10:43:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 32DA7ABCB; Tue, 19 May 2020 14:44:00 +0000 (UTC) Date: Tue, 19 May 2020 16:43:55 +0200 From: Petr Mladek To: Sergey Senozhatsky Cc: Eugeniu Rosca , linux-kernel@vger.kernel.org, John Ogness , Sergey Senozhatsky , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Jisheng Zhang , Valdis Kletnieks , Sebastian Andrzej Siewior , Andrew Gabbasov , Dirk Behme , Eugeniu Rosca Subject: Re: [RFC PATCH 3/3] watchdog: Turn console verbosity on when reporting softlockup Message-ID: <20200519144355.GN7340@linux-b0ei> References: <20200315170903.17393-1-erosca@de.adit-jv.com> <20200315170903.17393-4-erosca@de.adit-jv.com> <20200317021818.GD219881@google.com> <20200318180525.GA5790@lxhi-065.adit-jv.com> <20200319064836.GB24020@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200319064836.GB24020@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2020-03-19 15:48:36, Sergey Senozhatsky wrote: > On (20/03/18 19:05), Eugeniu Rosca wrote: > > My current standpoint is that as long as points [A-D] are met, it > > should do no harm to accept a (partial) fix like seen in my series: > > > > - [A] the patch tackles at least a subset of problematic use-cases > > - [B] the fix is non-intrusive and easy to review > > - [C] there is hope to reuse it in the new lockless buffer based printk > > - [D] there are no regressions employing the major console knobs > > (ignore_loglevel, quiet, loglevel, etc) as it happened in > > a6ae928c25835c ("Revert "printk: make sure to print log on console."") > > So the issue is that when we bump `console_loglevel' or `ignore_loglevel' > we lift restrictions globally. For all CPUs, for all contexts which call > printk(). This may have negative impact. Another impact is that many more messages might suddenly appear on the console even though admins wanted them quiet because they were slow. The problem is to define what information is critical. In the ideal world, all messages are visible on the console so that developers could use them for debugging. The console loglevel is there to keep it working in the real world. IMHO, an acceptable solution would be: + Print a single critical message about that a lockup happened + Make it configurable which log level will get used for the details. Note that there is a pending patchset that allows to show stacks with a given loglevel, see https://lore.kernel.org/linux-riscv/20200418201944.482088-1-dima@arista.com/ Well, I am slightly afraid that it might open a can with hundred of printk-related options shuffling log level for various events. The upcoming printk kthread might help to handle even more messages on slow consoles. It might allow to increase the default loglevel in these situations. But the problem will still be there. The throughput will always be limited and different people have different opinion on what messages are important. Best Regards, Petr