This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes
- From: Martin Hunt <hunt at redhat dot com>
- To: sourceware-bugzilla at sourceware dot org
- Cc: systemtap at sources dot redhat dot com
- Date: Wed, 29 Mar 2006 10:05:19 -0800
- Subject: Re: [Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes
- Organization: Red Hat Inc.
- References: <20060207171449.2293.fche@redhat.com> <20060329115458.29001.qmail@sourceware.org>
On Wed, 2006-03-29 at 11:54 +0000, fche at redhat dot com wrote:
> I recommend opening a new bug against the runtime, addressing specifically the
> issue of I/O buffering near the time of shutdown. I recall suggesting looking
> into whether stpd and the kernel-side runtime message handler can work together
> to drain the buffers before starting the module_exit process, to provide the
> maximum static space to the end probes. (That space amount would
> uncoincidentally match the command line option "-s NUM" to the initial
> compilation stage, and thus make some intuitive sense to the user.) Did you try
> that?
I think I originally suggested it, and I have thought further about it.
I hoped to find a better solution than imposing another limit users have
to compute. For collecting large amounts of data, MAXMAPENTRIES needs
raised and then you have to calculate how much space that data will take
up when "printed" into the output buffers. Another problem is that for
relayfs the buffer is divided into per-cpu sub-buffers. So the maximum
data that can be sent is NUM/cpus.
Martin