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;
Date:   Wed, 4 Sep 2019 14:35:31 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     John Ogness <john.ogness@linutronix.de>
Cc:     linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andrea Parri <andrea.parri@amarulasolutions.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Brendan Higgins <brendanhiggins@google.com>
Subject: Re: [RFC PATCH v4 0/9] printk: new ringbuffer implementation
Message-ID: <20190904123531.GA2369@hirez.programming.kicks-ass.net>
References: <20190807222634.1723-1-john.ogness@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190807222634.1723-1-john.ogness@linutronix.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 08, 2019 at 12:32:25AM +0206, John Ogness wrote:
> Hello,
> 
> This is a follow-up RFC on the work to re-implement much of
> the core of printk. The threads for the previous RFC versions
> are here: v1[0], v2[1], v3[2].
> 
> This series only builds upon v3 (i.e. the first part of this
> series is exactly v3). The main purpose of this series is to
> replace the current printk ringbuffer with the new
> ringbuffer. As was discussed[3], this is a conservative
> first step to rework printk. For example, all logbuf_lock
> usage is kept even though the new ringbuffer does not
> require it. This avoids any side-effect bugs in case the
> logbuf_lock is (unintentionally) synchronizing more than
> just the ringbuffer. However, this also means that the
> series does not bring any improvements, just swapping out
> implementations. A future patch will remove the logbuf_lock.

So after reading most of the first patch (and it look _much_ better than
previous times), I'm left wondering *why* ?!

That is, why do we need this complexity, as compared to that
CPU serialized approach?

What do we hope to gain by doing a multi-writer buffer? Yes, it is
awesome, but from where I'm sitting it is also completely silly, because
we'll want to CPU serialize the serial console anyway (otherwise it gets
to be a completely unreadable mess).

By having the whole thing CPU serialized we looose multi-writer and
consequently the buffer gets to be significantly simpler (as you know;
because ISTR you've actually done this before -- but I cannot find here
why that didn't live).

In my book simpler is better here. printk() is an absolute utter slow
path anyway, nobody cares about the performance much, and I'm thinking
that it should be plenty fast enough as long as you don't run a
synchronous serial output (which is exactly what I do do/require
anyway).

So can we have a few words to explain why we need multi-writer and all
this complexity?