statistics infrastructure - prerequisite: scatter-gather ringbuffer
PATCH 1/6 statistics infrastructure - prerequisite: scatter-gather ringbuffer
[patch 1/6] statistics infrastructure - prerequisite: scatter-gather ringbuffer
This patch implemenents a ringbuffer made up of scattered memory (pages). The current implementation allows fixed-size entries to be stored in the ringbuffer. There are routines that simplify writing entries to a buffer and reading entries from a buffer. Ringbuffer resizing is not supported, yet.
This is actually a separate feature which could be used for purposes other than statistics.
---
include/linux/sgrb.h | 92 ++++++++++++++ lib/Kconfig | 6 lib/Makefile | 2 lib/sgrb.c | 329 +++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 429 insertions(+)
include/linux/sgrb.h +92 -0
@@ -0,0 +1,92 @@ +/* +* include/linux/sgrb.h +* +* a ringbuffer made up of scattered buffers; +* holds fixed-size entries smaller than the size of underlying buffers +* (ringbuffer resizing has not been implemented) +* +* (C) Copyright IBM Corp. 2005 +* +* Author(s): Martin Peschke <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2, or (at your option) +* any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#ifndef SGRB_H +#define SGRB_H + +#define SGRB_H_REVISION "$Revision: 1.2 $" + +#include <linux/types.h> +#include <linux/slab.h> +#include <linux/list.h> + +#define SGRB_BUFFER_SIZE PAGE_SIZE + +struct sgrb_seg { +struct list_head list; +char *address; +int offset; +int size; +}; + +struct sgrb_ptr { +struct sgrb_seg *seg; +signed int offset; +}; + +struct sgrb { +struct list_head seg_lh; +struct sgrb_ptr first; +struct sgrb_ptr last; +int entry_size; +int entries; +}; + +/** +* sgrb_ptr_copy - prepare ringbuffer pointer a by copying b +* @a: duplicate +* @b: original +* +* required to prepare a ringbuffer pointer for use with sgrb_consume_nodelete() +*/ +static inline void sgrb_ptr_copy (struct sgrb_ptr *a,struct sgrb_ptr *b) +{ + a->seg = b->seg; + a->offset = b->offset; +} + +/** +* sgrb_entry - returns address of entry +* @a: ringbuffer pointer that determines entry +*/ +static inline void *sgrb_entry (struct sgrb_ptr *a) +{ +return (a->seg->address + a->offset); +} + +extern struct sgrb_seg *sgrb_seg_find (struct list_head *,int ,gfp_t ); +extern void sgrb_seg_release_all (struct list_head *); + +extern int sgrb_alloc (struct sgrb *,int ,int ,int ,gfp_t ); +extern void sgrb_release (struct sgrb *); +extern void sgrb_reset (struct sgrb *); + +extern void *sgrb_produce_overwrite (struct sgrb *); +extern void *sgrb_produce_nooverwrite (struct sgrb *); +extern void *sgrb_consume_delete (struct sgrb *); +extern void *sgrb_consume_nodelete (struct sgrb *,struct sgrb_ptr *); + +#endif /* SGRB_H */
lib/Kconfig +6 -0
@@ -86,4 +86,10 @@ config TEXTSEARCH_BM config TEXTSEARCH_FSM tristate +# +# Scatter-gather ring-buffer is select'ed if needed +# +config SGRB + boolean + endmenu
lib/Makefile +2 -0
@@ -46,6 +46,8 @@ obj-$(CONFIG_TEXTSEARCH_FSM) += ts_fsm.o obj-$(CONFIG_SWIOTLB) += swiotlb.o +obj-$(CONFIG_SGRB) += sgrb.o + hostprogs-y := gen_crc32table clean-files := crc32table.h
lib/sgrb.c +329 -0
329 lines not on this page · raw message
Quoted 9 lines · Martin Peschke
[patch 1/6] statistics infrastructure - prerequisite: scatter-gather ringbuffer
This patch implemenents a ringbuffer made up of scattered memory (pages). The current implementation allows fixed-size entries to be stored in the ringbuffer. There are routines that simplify writing entries to a buffer and reading entries from a buffer. Ringbuffer resizing is not supported, yet.
This is actually a separate feature which could be used for purposes other than statistics.
This seems redundant with relayfs.
-Andi
Quoted 11 lines · Andi Kleen
Quoted 7 lines · Martin Peschke
[patch 1/6] statistics infrastructure - prerequisite: scatter-gather ringbuffer
This patch implemenents a ringbuffer made up of scattered memory (pages). The current implementation allows fixed-size entries to be stored in the ringbuffer. There are routines that simplify writing entries to a buffer and reading entries from a buffer. Ringbuffer resizing is not supported, yet.
Quoted 11 lines
Quoted 4 lines
This is actually a separate feature which could be used for purposes other than statistics.
This seems redundant with relayfs.
-Andi
Interesting pointer.
Just having scanned through the relayfs documentation the first time, to me, relayfs looks like a combination of ringbuffer functionality, kernel-user space communication, and easy-to-use filesystem semantics.
Not sure I really need that much for my purposes. I was primarily looking for a simple way to temporarily store small bits of data in a larger buffer that wraps and isn't overly risky with regard to it's allocation. Both producer and consumer of the stored data are inside the kernel, or even within the same component.
Relayfs might be interesting for statistics, nonetheless, considering that there need to be a way to transfer data to user space.
Relayfs seems to be the right thing to convey streams of incremental pieces of data, like trace records as implemented by arch/s390/kernel/debug.c, for example. Relayfs would work for statistics that involve data growth like a history of a counter, for example, or the raw measurement data reported for statistic updates. I doubt it is the right thing for counters, fill level indicators and histograms; basically for all types of statistics that do not continuously put their hands on untouched memory to store their results.
I am currently using debugfs, which works fine for all of these cases. In addition, I need some ringbuffer functionality, though.
Quoted 6 lines
Relayfs seems to be the right thing to convey streams of incremental pieces of data, like trace records as implemented by
arch/s390/kernel/debug.c, for example. Relayfs would work for statistics that involve data growth like a history of a counter, for example, or the raw measurement data reported for statistic updates. I doubt it is the right thing for counters, fill level indicators and histograms;
For those we traditionally use ASCII files if the data is small. If it's big relayfs is probably the right answer.
Quoted 5 lines
basically for all types of statistics that do not continuously put their hands on untouched memory to store their results.
I am currently using debugfs, which works fine for all of these cases. In addition, I need some ringbuffer functionality, though.
IIRC relayfs was changed to be able to handle files in debuggfs by just plugging in the file operations.
-Andi