All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.