From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32324 invoked by alias); 29 Mar 2006 18:05:26 -0000 Received: (qmail 32315 invoked by uid 22791); 29 Mar 2006 18:05:25 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Mar 2006 18:05:23 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k2TI5M56004754; Wed, 29 Mar 2006 13:05:22 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k2TI5LgM001378; Wed, 29 Mar 2006 13:05:21 -0500 Received: from vpn83-152.boston.redhat.com (vpn83-152.boston.redhat.com [172.16.83.152]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k2TI5KTp027241; Wed, 29 Mar 2006 13:05:21 -0500 Subject: Re: [Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes From: Martin Hunt To: sourceware-bugzilla@sourceware.org Cc: systemtap@sources.redhat.com In-Reply-To: <20060329115458.29001.qmail@sourceware.org> References: <20060207171449.2293.fche@redhat.com> <20060329115458.29001.qmail@sourceware.org> Content-Type: text/plain Organization: Red Hat Inc. Date: Wed, 29 Mar 2006 18:05:00 -0000 Message-Id: <1143655519.2636.10.camel@dragon> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00888.txt.bz2 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