From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBSJ6rda027829 for ; Wed, 28 Dec 2005 14:06:53 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBSJ8jKp137880 for ; Wed, 28 Dec 2005 12:08:45 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jBSJ6rWg017070 for ; Wed, 28 Dec 2005 12:06:53 -0700 From: Tom Zanussi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17330.59716.136146.729098@tut.ibm.com> Date: Wed, 28 Dec 2005 13:36:36 -0600 Subject: Re: Better pagecache statistics ? In-Reply-To: <20051228013325.GA4144@dmt.cnet> References: <1133377029.27824.90.camel@localhost.localdomain> <20051201152029.GA14499@dmt.cnet> <20051228013325.GA4144@dmt.cnet> Sender: owner-linux-mm@kvack.org Return-Path: To: Marcelo Tosatti Cc: Badari Pulavarty , fche@redhat.com, linux-mm , lkml , systemtap@sources.redhat.com List-ID: Marcelo Tosatti writes: [...] > > b) ERROR: MAXACTION exceeded near identifier 'log' at ttfp_delay.stp:49:3 > > The array size is capped to a maximum. Is there any way to configure > SystemTap to periodically dump-and-zero the arrays? This makes lots of > sense to any statistical gathering code. > > c) Hash tables > > It would be better to store the log entries in a hash table, the present > script uses the "current" pointer as a key into a pair of arrays, > incrementing the key until a free one is found (which can be very > inefficient). > > A hash table would be much more efficient, but allocating memory inside > the scripts is tricky. A pre-allocated, pre-sized pool of memory could > work well for this purpose. The "dump-array-entries-to-userspace" action > could be used to free them. > > So both b) and c) could be fixed with the same logic: > > - dump entries to userspace if memory pool is getting short > on free entries. > - periodically dump entries to userspace (akin to "bdflush"). Hi, There's a sytemtap example that does something similar to what you're describing - see the kmalloc-stacks/kmalloc-top examples in the testsuite: systemtap/tests/systemtap.samples/kmalloc-stacks.stp systemtap/tests/systemtap.samples/kmalloc-top Basically, the kmalloc-stacks.stp script hashes data in a systemtap hash and periodically formats the current contents of the hash table into a convenient form and writes it to userspace, then clears the hash for the next go-round. kmalloc-top is a companion Perl script 'daemon' that sits around in userspace waiting for new batches of hash data, which it then adds to a continuously accumulating Perl hash in the user-side script. There's a bit more detail about the script(s) here: http://sourceware.org/ml/systemtap/2005-q3/msg00550.html HTH, Tom -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org