This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug runtime/10189] STP_START gets lost in a warning flood
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 17 Nov 2009 17:31:20 -0000
- Subject: [Bug runtime/10189] STP_START gets lost in a warning flood
- References: <20090522204505.10189.jistone@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From fche at redhat dot com 2009-11-17 17:31 -------
(In reply to comment #2)
> Current stap will keep allocating buffer for _stp_warn in probe until
> out of memory.
That's wrong; script-accessible constructs like error()/warn() should
not be able to deplete a dynamically allocated resource. OTOH in this
case it looks like the transport is just using its own _stp_mempool_alloc,
which at least is a private resource.
> Maybe it's better to make _stp_warn utilize _stp_print instead of
> _stp_ctl_write.
Then we'd have the same problem with error(). The OOB messages do serve a
useful purpose at staprun time, so let's find a way of preserving OOB while
ensuring that the basic protocol can proceed.
For example, we can know that some of these kernel->staprun messages only
occur singly (i.e., are not queued en masse). So for them, we could
preallocate a mem_buffer element, to avoid having them contend. One way
would be to have separate mempools for each message type, and ensuring
that the singleton messages only allocate one or two elements total.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10189
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.