Re: Better pagecache statistics ?
From: Frank Ch. Eigler
Date: Fri Dec 02 2005 - 17:46:50 EST
Hi -
On Fri, Dec 02, 2005 at 02:31:56PM -0800, Badari Pulavarty wrote:
> On Fri, 2005-12-02 at 17:15 -0500, Frank Ch. Eigler wrote:
> [...]
> > #! stap
> > probe kernel.function("add_to_page_cache") {
> > printf("pid %d added pages (%d)\n", pid(), $mapping->nrpages)
> > }
> > probe kernel.function("__remove_from_page_cache") {
> > printf("pid %d removed pages (%d)\n", pid(), $page->mapping->nrpages)
> > }
>
> [...] Having by "pid" basis is not good enough. I need per
> file/mapping basis collected and sent to user-space on-demand.
If you can characterize all your data needs in terms of points to
insert hooks (breakpoint addresses) and expressions to sample there,
systemtap scripts can probably track the relationships. (We have
associative arrays, looping, etc.)
> Is systemtap hooked to relayfs to send data across to user-land ?
> printf() is not an option.
systemtap can optionally use relayfs. The printf you see here does
not relate to/invoke the kernel printk, if that's what you're worried
about.
> And also, I need to have this probe, installed from the boot time
> and collecting all the information - so I can access it when I need
> it
We haven't done much work yet to address on-demand kind of interaction
with a systemtap probe session. However, one could fake it by
associating data-printing operations with events that are triggered
purposely from userspace, like running a particular system call from a
particularly named process.
> which means this bloats kernel memory. [...]
The degree of bloat is under the operator's control: systemtap only
uses initialization-time memory allocation, so its arrays can fill up.
- FChE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/