From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22124 invoked by alias); 29 Jan 2008 17:08:01 -0000 Received: (qmail 17996 invoked by uid 48); 29 Jan 2008 17:07:20 -0000 Date: Tue, 29 Jan 2008 17:08:00 -0000 Message-ID: <20080129170720.17995.qmail@sourceware.org> From: "hunt at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20071018140048.5194.hunt@redhat.com> References: <20071018140048.5194.hunt@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/5194] IO problem on begin/end probes; need X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00172.txt.bz2 ------- Additional Comments From hunt at redhat dot com 2008-01-29 17:07 ------- > Unless you have a scenario that could explain cpu switching, or an > actual test case that demonstrates it occurring, let's please close > this bug. Something could only happen now if code included using "-g" slept during a begin or end probe. The only reason to ever do so that I can think of is because we decide to change IO to timeout and retry on error during end probes. And the reason to do that is because in extreme cases, on single-cpu systems, the total data collected in arrays and being dumped in the end probe exceeds the free space in the relayfs buffer. So we have to free the cpu and let stapio read from the relayfs buffer to continue. Such a situation would be rare and we could just say the proper fix is to simply use "-s" to set the buffer size larger. I'm fine with that, at least for now. We have bigger fish to fry. -- What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED Resolution| |WONTFIX http://sourceware.org/bugzilla/show_bug.cgi?id=5194 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.