This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes
- From: "hunt at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 29 Mar 2006 18:05:29 -0000
- Subject: [Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes
- References: <20060207171449.2293.fche@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From hunt at redhat dot com 2006-03-29 18:05 -------
Subject: Re: confirm preemption/interrupt blocking in
systemtap probes
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
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2293
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.