From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: linux-mm <linux-mm@kvack.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Better pagecache statistics ?
Date: Thu, 1 Dec 2005 16:15:25 -0200 [thread overview]
Message-ID: <20051201181525.GB17169@dmt.cnet> (raw)
In-Reply-To: <1133458309.21429.36.camel@localhost.localdomain>
> > I thought that it would be easy to use SystemTap for a such
> > a purpose?
> >
> > The sys_read/sys_write example at
> > http://www.redhat.com/magazine/011sep05/features/systemtap/ sounds
> > interesting.
> >
> > What I'm I missing?
>
> Well, Few things:
>
> 1) We have to have those probes present in the system all the time
> collecting the information when read/write happens, maintaining it
> and spitting it out. Since its kernel probe, all this data will be
> in the kernel.
Yeah, there is some overhead.
> 2) If we want to do this accounting (and you don't have those probes
> installed already) - we can't capture what happened earlier.
I suppose that the vast majority of situations where such information is
needed are special anyway?
Why do you need it around all the time?
> 3) probing sys_read/sys_write() are going to tell you how much
> a data a process did read or wrote - but its not going to tell you
> how much is in the cache (now or 10 minutes later).
Sure, that was just an example - need to insert probes
on the correct places.
> > > My final goal is to get stats like ..
> > >
> > > Out of "Cached" value - to get details like
> > >
> > > <mmap> - xxx KB
> > > <shared mem> - xxx KB
> > > <text, data, bss, malloc, heap, stacks> - xxx KB
> > > <filecache pages total> -- xxx KB
> > > (filename1 or <dev>, <ino>) -- #of pages
> > > (filename2 or <dev>, <ino>) -- #of pages
> > >
> > > This would be really powerful on understanding system better.
> > >
> > > Don't you think ?
> >
> > Yep... /proc/<pid>/smaps provides that information on a per-process
> > basis already.
>
> /proc/pid/smaps will give me information about text,data,shared libs,
> malloc etc. Not the filecache information about files process opened,
> pages read/wrote currently in the pagecache. Isn't it ?
Right.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: linux-mm <linux-mm@kvack.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Better pagecache statistics ?
Date: Thu, 1 Dec 2005 16:15:25 -0200 [thread overview]
Message-ID: <20051201181525.GB17169@dmt.cnet> (raw)
In-Reply-To: <1133458309.21429.36.camel@localhost.localdomain>
> > I thought that it would be easy to use SystemTap for a such
> > a purpose?
> >
> > The sys_read/sys_write example at
> > http://www.redhat.com/magazine/011sep05/features/systemtap/ sounds
> > interesting.
> >
> > What I'm I missing?
>
> Well, Few things:
>
> 1) We have to have those probes present in the system all the time
> collecting the information when read/write happens, maintaining it
> and spitting it out. Since its kernel probe, all this data will be
> in the kernel.
Yeah, there is some overhead.
> 2) If we want to do this accounting (and you don't have those probes
> installed already) - we can't capture what happened earlier.
I suppose that the vast majority of situations where such information is
needed are special anyway?
Why do you need it around all the time?
> 3) probing sys_read/sys_write() are going to tell you how much
> a data a process did read or wrote - but its not going to tell you
> how much is in the cache (now or 10 minutes later).
Sure, that was just an example - need to insert probes
on the correct places.
> > > My final goal is to get stats like ..
> > >
> > > Out of "Cached" value - to get details like
> > >
> > > <mmap> - xxx KB
> > > <shared mem> - xxx KB
> > > <text, data, bss, malloc, heap, stacks> - xxx KB
> > > <filecache pages total> -- xxx KB
> > > (filename1 or <dev>, <ino>) -- #of pages
> > > (filename2 or <dev>, <ino>) -- #of pages
> > >
> > > This would be really powerful on understanding system better.
> > >
> > > Don't you think ?
> >
> > Yep... /proc/<pid>/smaps provides that information on a per-process
> > basis already.
>
> /proc/pid/smaps will give me information about text,data,shared libs,
> malloc etc. Not the filecache information about files process opened,
> pages read/wrote currently in the pagecache. Isn't it ?
Right.
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-12-01 18:15 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-30 18:57 Better pagecache statistics ? Badari Pulavarty
2005-11-30 18:57 ` Badari Pulavarty
2005-12-01 2:35 ` Hareesh Nagarajan
2005-12-01 2:35 ` Hareesh Nagarajan
2005-12-01 15:20 ` Marcelo Tosatti
2005-12-01 15:20 ` Marcelo Tosatti
2005-12-01 15:59 ` Badari Pulavarty
2005-12-01 15:59 ` Badari Pulavarty
2005-12-01 16:10 ` Arjan van de Ven
2005-12-01 16:10 ` Arjan van de Ven
2005-12-01 16:23 ` Badari Pulavarty
2005-12-01 16:23 ` Badari Pulavarty
2005-12-01 17:08 ` Marcelo Tosatti
2005-12-01 17:08 ` Marcelo Tosatti
2005-12-01 17:15 ` Badari Pulavarty
2005-12-01 17:15 ` Badari Pulavarty
2005-12-01 17:21 ` Arjan van de Ven
2005-12-01 17:21 ` Arjan van de Ven
2005-12-01 17:57 ` Marcelo Tosatti
2005-12-01 17:57 ` Marcelo Tosatti
2005-12-01 18:20 ` Badari Pulavarty
2005-12-01 18:20 ` Badari Pulavarty
2005-12-02 22:15 ` Frank Ch. Eigler
2005-12-02 22:15 ` Frank Ch. Eigler
2005-12-02 22:31 ` Badari Pulavarty
2005-12-02 22:31 ` Badari Pulavarty
2005-12-02 22:46 ` Frank Ch. Eigler
2005-12-02 22:46 ` Frank Ch. Eigler
2005-12-02 23:46 ` Badari Pulavarty
2005-12-01 18:24 ` Badari Pulavarty
2005-12-01 18:24 ` Badari Pulavarty
2005-12-04 18:48 ` Martin J. Bligh
2005-12-04 18:48 ` Martin J. Bligh
2005-12-01 17:19 ` Marcelo Tosatti
2005-12-01 17:19 ` Marcelo Tosatti
2005-12-01 17:31 ` Badari Pulavarty
2005-12-01 17:31 ` Badari Pulavarty
2005-12-01 18:15 ` Marcelo Tosatti [this message]
2005-12-01 18:15 ` Marcelo Tosatti
2005-12-01 18:25 ` Badari Pulavarty
2005-12-01 18:25 ` Badari Pulavarty
2005-12-01 16:00 ` Marcelo Tosatti
2005-12-01 16:00 ` Marcelo Tosatti
2005-12-01 21:16 ` Christoph Lameter
2005-12-01 21:16 ` Christoph Lameter
2005-12-02 0:13 ` Badari Pulavarty
2005-12-02 0:13 ` Badari Pulavarty
2005-12-28 1:33 ` Marcelo Tosatti
2005-12-28 1:33 ` Marcelo Tosatti
2005-12-28 19:36 ` Tom Zanussi
2005-12-28 19:36 ` Tom Zanussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051201181525.GB17169@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbadari@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.