Messages in this thread | | | From | Tom Zanussi <> | Date | Wed, 28 Dec 2005 13:36:36 -0600 | Subject | Re: Better pagecache statistics ? |
| |
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |