From: John Ogness <john.ogness@linutronix.de>
To: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.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: [RFC PATCH v3 0/2] printk: new ringbuffer implementation
Date: Sat, 27 Jul 2019 03:33:31 +0200 [thread overview]
Message-ID: <20190727013333.11260-1-john.ogness@linutronix.de> (raw)
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].
As was planned[2], this is only the first piece: a new
lockless ringbuffer.
Changes from v2:
- Moved all code into kernel/printk/. Let's keep it private
for now.
- Split the ringbuffer into 3 components:
* a data ringbuffer (dataring) to manage the raw data and
data descriptors
* a numbered list (numlist) to manage committed entries and
their sequence numbers
* the printk_ringbuffer, which is the high-level structure
providing the reader/writer API and glue for the other
structures
Splitting the components apart helped to document their
roles and their related memory barriers (and will hopefully
also simplify the review process).
- Renamed most functions, structures, and variables based on
v2 feedback.
- Rewrote and reformatted nearly all comments (particularly
the memory barrier comments) based on v2 feedback.
- Addressed implementation issues with v2:
* invalid data blocks potentially becoming valid because of
overflows
* weak associations between data blocks and descriptors
* excessive freeing of data blocks due to unavailable
descriptors
- Improved error handling and data integrity checks in the test
module.
For the memory barrier work I wrote a litmus test for nearly
every memory barrier. I did not include these in the series.
Should I? If yes, where should they be placed?
I would like to point out that Petr Mladek posted a
proof-of-concept[3] alternate implementation. I wanted to base my
v3 on his work, but ran into too many problems getting it to
run acceptably. I will address those issues in that thread. This
is why my v3 is based directly on my v2.
John Ogness
[0] https://lkml.kernel.org/r/20190212143003.48446-1-john.ogness@linutronix.de
[1] https://lkml.kernel.org/r/20190607162349.18199-1-john.ogness@linutronix.de
[2] https://lkml.kernel.org/r/87y35hn6ih.fsf@linutronix.de
[3] https://lkml.kernel.org/r/20190704103321.10022-1-pmladek@suse.com
John Ogness (2):
printk-rb: add a new printk ringbuffer implementation
printk-rb: add test module
kernel/printk/Makefile | 5 +
kernel/printk/dataring.c | 761 ++++++++++++++++++++++++++++++++++++++++++
kernel/printk/dataring.h | 95 ++++++
kernel/printk/numlist.c | 375 +++++++++++++++++++++
kernel/printk/numlist.h | 72 ++++
kernel/printk/ringbuffer.c | 800 +++++++++++++++++++++++++++++++++++++++++++++
kernel/printk/ringbuffer.h | 288 ++++++++++++++++
kernel/printk/test_prb.c | 256 +++++++++++++++
8 files changed, 2652 insertions(+)
create mode 100644 kernel/printk/dataring.c
create mode 100644 kernel/printk/dataring.h
create mode 100644 kernel/printk/numlist.c
create mode 100644 kernel/printk/numlist.h
create mode 100644 kernel/printk/ringbuffer.c
create mode 100644 kernel/printk/ringbuffer.h
create mode 100644 kernel/printk/test_prb.c
--
2.11.0
next reply other threads:[~2019-07-27 1:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-27 1:33 John Ogness [this message]
2019-07-27 1:33 ` [RFC PATCH v3 1/2] printk-rb: add a new printk ringbuffer implementation John Ogness
2019-07-27 1:33 ` [RFC PATCH v3 2/2] printk-rb: add test module John Ogness
2019-07-31 6:46 ` John Ogness
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190727013333.11260-1-john.ogness@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=andrea.parri@amarulasolutions.com \
--cc=brendanhiggins@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.