linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Peschke <mp3@de.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 1/6] statistics infrastructure - prerequisite: scatter-gather ringbuffer
Date: Thu, 15 Dec 2005 03:35:57 +0100	[thread overview]
Message-ID: <43A0D68D.8090405@de.ibm.com> (raw)
In-Reply-To: <p73d5jz8r7n.fsf@verdi.suse.de>

Andi Kleen wrote:

>Martin Peschke <mp3@de.ibm.com> writes:
>
>  
>
>>[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
>
>  
>
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.


  reply	other threads:[~2005-12-15  2:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14 16:13 [patch 1/6] statistics infrastructure - prerequisite: scatter-gather ringbuffer Martin Peschke
2005-12-14 18:32 ` Andi Kleen
2005-12-15  2:35   ` Martin Peschke [this message]
2005-12-15  3:33     ` Andi Kleen

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=43A0D68D.8090405@de.ibm.com \
    --to=mp3@de.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).