This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: streaming output options
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Martin Hunt <hunt at redhat dot com>
- Cc: systemtap at sources dot redhat dot com, ananth at in dot ibm dot com, Tom Zanussi <zanussi at us dot ibm dot com>
- Date: 08 May 2007 14:22:41 -0400
- Subject: Re: streaming output options
- References: <463A32E8.7010306@redhat.com> <20070508062139.GA20353@in.ibm.com> <20070508114116.GI19620@redhat.com> <mailman.1178640841.13231.external-perftools-list@redhat.com> <y0mbqgvp6pq.fsf@ton.toronto.redhat.com> <1178647895.4852.34.camel@dragon>
Martin Hunt <hunt@redhat.com> writes:
> [...]
> Let me explain in more detail. Perhaps I am missing some options, but
> these seem to be the options we have.
> 1. A single file that contains the data. Can use with "cat",
> third-party apps. To do this, merging must be in the kernel. That
> means some blocking must occur. [...]
With double-buffering, this may not need to happen too frequently.
The processors could write into alternating buffers of their own. The
read() handler of the hypothetical combined file could quickly switch
buffers (so the processors keep on writing into private, uncontended
areas), and then merge from the ones it borrowed.
> 2. Per-cpu files that are merged into a single stream in
> userspace. [...]
> Anything else?
How about *both*, activating in-kernel merging only if userspace opens
the combined file.
- FChE