Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4544357ybl; Tue, 21 Jan 2020 23:33:05 -0800 (PST) X-Google-Smtp-Source: APXvYqyQ0HeCmC1/FS5i0d8snWra680o8imj6u+CeTAAYUphjjwIxGNQjuV5lLvy3BlWlsqZaQ/n X-Received: by 2002:a05:6830:ce:: with SMTP id x14mr6628803oto.105.1579678385165; Tue, 21 Jan 2020 23:33:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579678385; cv=none; d=google.com; s=arc-20160816; b=IR2DV7h8vzl1KFw53U7NjiwdYSh9hoW6k8SF0bMvU31OnJ6CZ85Z0EA6M9dPwAQ34s jEiVOX0qYLs8npjAAuS6lOwFmjNRnh0QVLZUGafVWIxTNM7L6e9kot9XaZi9ynjeKjpl 25JDqPPnLERGZj/gq8LvYv+ZEckoQXXzFxMWY4F78kIOEO7DnGOsJfGWjImIN/ugzY2r xt8vF5hOps57muQnlfuwhvlkBQxy6RyzNcWtNs6mKzlSdGu3tSiBWoeTUG/iNQ0JQA4x QAPXIxML3H734OwyhyLlnRhwRSMZDKS9ec3bWJvUAJ15ZodAdeMz6WkY24mrxWs8GcTa cSbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=RqVNk/s/kihSN6HM/Xmr4Y73WPhhKATV/QFQjnujpGg=; b=rhAdHlFAg9VaxiMQcN6EvrNcShcqnBjXPCmst7h/SgKNFtgHSAuB5teXJZUfeiQSl0 Te3BtNDhDpLf0XJKOi+vKJkQUPKwh6tU5JiTZyGUSa61BHmfC7a0cpd2vA+9lw1cTpJA cJYjqwNLEC0XjMUcYd68Yi2bRqnkTqxK8LUzS0XZvn3e0E+CAUDQ84bxZvlkvEiW3z/I QyS8fRpff2/omJqBAcazEqWZGNcqjgEtkL+qM7SJv0dsBqt0zGLX3+dUz3T9EE0dbGvx DFfsr3qvSGbGOyQ0Q4KSu7Jllhms542f3maw/8h2fzTKT9aoXJ440ALGMCzsWJvqCqJQ zCgA== 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 5si20675086oiy.102.2020.01.21.23.32.52; Tue, 21 Jan 2020 23:33:05 -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 S1726083AbgAVHb5 (ORCPT + 99 others); Wed, 22 Jan 2020 02:31:57 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:44355 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725883AbgAVHb5 (ORCPT ); Wed, 22 Jan 2020 02:31:57 -0500 Received: by mail-oi1-f193.google.com with SMTP id d62so5187162oia.11; Tue, 21 Jan 2020 23:31:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RqVNk/s/kihSN6HM/Xmr4Y73WPhhKATV/QFQjnujpGg=; b=nJRSl2fSm18QROdiFpbHUDOaYyDmK8vbbYkRZUGkbHC9Ybn7U22QmcJrsPYOfZhM1F U18hf5/hAtdgeHh7x/+jb6Af7u431VGhT+/KH7FYrYcPAu3BooWbMxESMYcSo/2FkiXY nSKFNPEBWO+oudG6FG6qINt0DXzQqFsILmnOvw5GNt+HmeY/H5nnKUSjhBtjlOL9VWxI UiIyIq0RBMDGfbE13o5FeUMj75hv7WYB+HjkERu43AcyZHNgeKDvaK6FUV+HqGbMPq+Z lLeN74uwKQ4qia7kmeK06JGw9KZNIQr0eXqs2n7gwhI/bzJfZMqkWMhympN+7uXN6iiN Q1oA== X-Gm-Message-State: APjAAAULh8+p3VgMlXxQtQBTn/nXuTAuxah7uDSwWoyvOoHw2sP3uJrh CBfjnqnqqNOvrevyl1vfCZ6IicKi7jKVFN62Rqo= X-Received: by 2002:a05:6808:292:: with SMTP id z18mr5610666oic.131.1579678316554; Tue, 21 Jan 2020 23:31:56 -0800 (PST) MIME-Version: 1.0 References: <20190212143003.48446-1-john.ogness@linutronix.de> <20200120230522.GA23636@lxhi-065.adit-jv.com> <87v9p4mkhr.fsf@linutronix.de> <20200122023422.GA926@lxhi-065.adit-jv.com> In-Reply-To: <20200122023422.GA926@lxhi-065.adit-jv.com> From: Geert Uytterhoeven Date: Wed, 22 Jan 2020 08:31:44 +0100 Message-ID: Subject: Re: [RFC PATCH v1 00/25] printk: new implementation To: Eugeniu Rosca Cc: John Ogness , Linux Kernel Mailing List , Peter Zijlstra , Geert Uytterhoeven , Kuninori Morimoto , Andrew Gabbasov , Sanjeev Chugh , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Daniel Wang , Dean Jenkins , Andrew Morton , Linus Torvalds , Greg Kroah-Hartman , Dirk Behme , Alan Cox , Jiri Slaby , Peter Feiner , "open list:SERIAL DRIVERS" , Sergey Senozhatsky , Eugeniu Rosca Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eugeniu, On Wed, Jan 22, 2020 at 3:34 AM Eugeniu Rosca wrote: > On Wed, Jan 22, 2020 at 12:56:48AM +0100, John Ogness wrote: > > On 2020-01-21, Eugeniu Rosca wrote: > > > This [1] is a fairly old thread, but I only recently stumbled upon it, > > > while co-investigating below audio distortions [2] on R-Car3 ARM64 > > > boards, which can be reproduced by stressing [3] the serial console. > > > > > > The investigation started a few months ago, when users reported audio > > > drops during the first seconds of system startup. Only after a few > > > weeks it became clear (thanks to some people in Cc) that the > > > distortions were contributed by the above-average serial console load > > > during the early boot. Once understood, we were able to come up with a > > > synthetic test [2-3]. > > > > > > I thought it would be interesting to share below reproduction matrix, > > > in order to contrast vanilla to linux-rt-devel [4], as well as to > > > compare various preemption models. > > > > > > | Ser.console Ser.console > > > | stressed at rest or disabled > > > -------------------------------------------- > > > v5.5-rc6 (PREEMPT=y) | distorted clean > > > v5.4.5-rt3 (PREEMPT=y) | distorted clean > > > v5.4.5-rt3 (PREEMPT_RT=y) | clean clean > > > > > > My feeling is that the results probably do not surprise linux-rt > > > people. > > > > > > My first question is, should there be any improvement in the case of > > > v5.4.5-rt3 (PREEMPT=y), which I do not sense? I would expect so, based > > > on the cover letter of this series (pointing out the advantages of the > > > redesigned printk mechanism). > > > > The problem you are reporting is not the problem that the printk rework > > is trying to solve. > > In general, agreed. But there are some quirks and peculiarities in how > the issue (increased audio latency) manifests itself on R-Car3, which > might create some room for a (relatively simple) loophole solution in > the printk mechanism. > > With that said, I need to diverge a bit from the platform-agnostic > scope of this series. > > So, what's specific to R-Car3, based on my testing, is that the issue > can only be reproduced if the printk storm originates on CPU0 (it does > not matter if from interrupt or task context, both have been tested). If > the printk storm is initiated on any other CPU (there are 7 secondary > ones on R-Car H3), there is no regression in the audio quality/latency. The secure stuff is running on CPU0, isn't it? Is that a coincidence? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds