From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14248 invoked by alias); 5 May 2006 16:38:22 -0000 Received: (qmail 14241 invoked by uid 22791); 5 May 2006 16:38:21 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_20,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; Fri, 05 May 2006 16:38:20 +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 k45GcIgm016111 for ; Fri, 5 May 2006 12:38:18 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k45GcIXC014526 for ; Fri, 5 May 2006 12:38:18 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k45GcHbj020679 for ; Fri, 5 May 2006 12:38:17 -0400 Received: from ton.toronto.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id AFE3580004C for ; Fri, 5 May 2006 12:38:17 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id k45GcHi7002019 for ; Fri, 5 May 2006 12:38:17 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id k45GcHEW002018 for systemtap@sources.redhat.com; Fri, 5 May 2006 12:38:17 -0400 Date: Fri, 05 May 2006 16:38:00 -0000 From: "Frank Ch. Eigler" To: systemtap@sources.redhat.com Subject: Re: [Bug translator/2293] confirm preemption/interrupt blocking in systemtap probes Message-ID: <20060505163817.GA18501@redhat.com> References: <20060207171449.2293.fche@redhat.com> <20060505160951.1801.qmail@sourceware.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060505160951.1801.qmail@sourceware.org> User-Agent: Mutt/1.4.1i 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-q2/txt/msg00319.txt.bz2 varap wrote: > There is a generic problem that we have to solve in SystemTap to > support long running or large number of probes. The common problem > with these scenarios is, they generate lot more data than the maps > can hold. Let's turn the question around for a moment: how big arrays can we safely support? What's the largest MAXMAPENTRIES people have tried? > 1) We should have capability to say truncate the map by leaving only > the top "n" entries based on the key. If one is looking to get > general trends top few is more than enough hence this solution could > be useful. That's an interesting idea. Such a partial-delete operation would have to be used carefully, since e.g. it destroys information that could raise a low-ranked value from rising into the preserved few. In other words, truncating periodically is not equivalent to truncating once at the end. > 2) Second solution is able to periodically dump the maps to > userspace and then stpd during the post processing can reconstruct > the full maps from the dumps. [...] For "write-only" maps such as dtrace aggregates, this sort of thing could work. In systemtap, all arrays are in general read/write, so this would apply only in restricted cases and/or with moving some processing over along with the data. Ordinary trace data could of course be post-processed by user-space scripts. - FChE