This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Better pagecache statistics ?
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Badari Pulavarty <pbadari at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 2 Dec 2005 20:59:29 -0500
- Subject: Re: Better pagecache statistics ?
- References: <1133453411.2853.67.camel@laptopd505.fenrus.org> <20051201170850.GA16235@dmt.cnet> <1133457315.21429.29.camel@localhost.localdomain> <1133457700.2853.78.camel@laptopd505.fenrus.org> <20051201175711.GA17169@dmt.cnet> <1133461212.21429.49.camel@localhost.localdomain> <y0md5kfxi15.fsf@tooth.toronto.redhat.com> <1133562716.21429.103.camel@localhost.localdomain> <20051202224645.GB6576@redhat.com> <1133567206.21429.117.camel@localhost.localdomain>
Hi -
(Redirected from http://lkml.org/lkml/2005/12/1/182)
Badari Pulavarty wrote:
> [...] Is there a way another user-level program/utility access some
> of the data maintained in those arrays ?
Not really. One possibility is an on-demand /proc interface outlined
in systemtap bug #1154.
> [...]
> Does this mean that I can do something like
> page_cache[0xffff8100c4c6b298] = $mapping->nrpages ?
> And this won't generate bloated arrays ?
If by "bloat" you mean "trying to allocate 2**64 elements", then no,
it won't do that. Systemtap associative arrays are more like hash
tables.
> [...] Unfortunately, I can't capture whatever happend before
> inserting the problem. So it won't give me information about all
> whats there in the pagecache.
Until other mechanisms become available, one could perhaps start the
probe early on during boot.
> BTW, if you prefer - we can move the discussion to systemtap.
Done.
- FChE