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;
From:   Prarit Bhargava <prarit@redhat.com>
To:     prarit@redhat.com
Cc:     andrea.parri@amarulasolutions.com, brendanhiggins@google.com,
        gregkh@linuxfoundation.org, john.ogness@linutronix.de,
        kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
        peterz@infradead.org, pmladek@suse.com, rostedt@goodmis.org,
        sergey.senozhatsky@gmail.com, sergey.senozhatsky.work@gmail.com,
        tglx@linutronix.de, torvalds@linux-foundation.org
Subject: Re: [RFC PATCH v5 0/3] printk: new ringbuffer implementation
Date:   Fri,  6 Dec 2019 09:16:53 -0500
Message-Id: <20191206141653.1199-1-prarit@redhat.com>
In-Reply-To: <87zhg6zx31.fsf@linutronix.de>
References: <87zhg6zx31.fsf@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

  John Ogness <john.ogness@linutronix.de> wrote:
> Hi Prarit,
>=20
> On 2019-12-05, Prarit Bhargava <prarit@redhat.com> wrote:
> > Based on the comments there is going to be a v6 but in any case I am
> > starting testing of this patchset on several large core systems across
> > multiple architectures (x86_64, ARM64, s390, ppc64le).  Some of those
> > systems are known to fail boot due to the large amount of printk output=
 so
> > it will be good to see if these changes resolve those issues.
>=20
> Right now the patches only include the ringbuffer as a separate entity
> with a test module. So they do not yet have any effect on printk.
>=20
> If you apply the patches and then build the "modules" target, you will
> have a new test_prb.ko module. Loading that module will start some heavy
> testing of the ringbuffer. As long as the testing is successful, the
> module will keep testing. During this time the machine will be very
> slow, but should still respond.
>=20
> The test can be stopped by unloading the module. If the test stops on
> its own, then a problem was found. The output of the test is put into
> the ftrace buffer.
>=20
> It would be nice if you could run the test module on some fat machines,
> at least for a few minutes to see if anything explodes. ARM64 and
> ppc64le will probably be the most interesting, due to memory barrier
> testing.
>=20

I've run the module overnight on all 4 arches I mentioned above.  I didn't
see any failures but IIUC the module test runs at max.  I'm going to put a
load test on these systems that introduces a variable load to interfere
with the prbtest module to see if that kicks anything.

> Otherwise I will definitely be reaching out to you when we are ready to
> perform actual printk testing with the newly agreed up semantics
> (lockless, per-console printing threads, synchronous panic
> consoles). Thanks for your help with this.
>

np :) but I should be the one thanking you ;)

P.

> John Ogness