From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2252 invoked by alias); 28 Dec 2005 20:12:51 -0000 Received: (qmail 2243 invoked by uid 22791); 28 Dec 2005 20:12:50 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hera.kernel.org (HELO hera.kernel.org) (140.211.167.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Dec 2005 20:12:48 +0000 Received: from dmt.cnet (localhost [127.0.0.1]) by hera.kernel.org (8.13.1/8.13.1) with ESMTP id jBSKCaM1018534; Wed, 28 Dec 2005 12:12:36 -0800 Received: from dmt.cnet (dmt.cnet [127.0.0.1]) by dmt.cnet (Postfix) with ESMTP id 0FF6030AA6C; Wed, 28 Dec 2005 18:12:51 -0200 (BRST) Received: (from marcelo@localhost) by dmt.cnet (8.13.4/8.13.4/Submit) id jBSKCn1m009389; Wed, 28 Dec 2005 18:12:49 -0200 Date: Wed, 28 Dec 2005 20:38:00 -0000 From: Marcelo Tosatti To: Tom Zanussi Cc: "Frank Ch. Eigler" , James Dickens , systemtap@sources.redhat.com Subject: Re: MAXACTION exceeded error while using systemtap Message-ID: <20051228201249.GA8405@dmt.cnet> References: <20051206221109.GE9617@redhat.com> <1133988833.4007.20.camel@monkey2> <20051207210948.GH9617@redhat.com> <1133994611.4007.60.camel@monkey2> <20051207230653.GI9617@redhat.com> <1134032140.4114.24.camel@monkey2> <20051208135746.GL9617@redhat.com> <20051228164538.GA3709@dmt.cnet> <17330.60599.330907.78327@tut.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17330.60599.330907.78327@tut.ibm.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.85, clamav-milter version 0.85 on localhost X-Virus-Status: Clean 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: 2005-q4/txt/msg00559.txt.bz2 > > I think that SystemTap needs some method to periodically (or when memory > > pressure arrives) dump the parts of the array to userspace via > > relayfs. > > See my previous reply for one way you could do this i.e. the > kmalloc-stacks example. Will take a look - seems promising. > > relayfs already supports such mechanism with its "sub-buffer" structure, > > where the userspace reader is allowed to read full buffers (thus freeing > > them afterwards) while the hooks continue to push data to empty or > > partially filled buffers. > > > > James mentions that > > > > "btw MAXACTION really can't work reliably what happens when the box is > > underload, say with 4 gigabit nics all being flooded with data, and > > you are probing a function in the fast path? > > > > Not everyone has a box that can sum 4 billion numbers in less than a minute." > > > > relayfs works in two modes once its memory pool is full: > > > > - panic's > > - drops new entries > > > > I imagine that by using relayfs to send data to userspace one should > > automatically get those very important features. > > I'm not sure what you mean - relayfs can be used in either 'overwrite' > or 'no-overwrite' modes; if its memory pool is full, 'overwrite' mode > overwrites the oldest entries, while 'no-overwrite' mode drops new > entries - there should be no 'panic's' anywhere in there. ;-) Indeed - there's no "panic" anywhere. Your description is accurate (unlike mine's) :)