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 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 index 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 " 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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git