From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Better pagecache statistics ?
Date: Thu, 1 Dec 2005 15:57:11 -0200 [thread overview]
Message-ID: <20051201175711.GA17169@dmt.cnet> (raw)
In-Reply-To: <1133457700.2853.78.camel@laptopd505.fenrus.org>
On Thu, Dec 01, 2005 at 06:21:39PM +0100, Arjan van de Ven wrote:
> On Thu, 2005-12-01 at 09:15 -0800, Badari Pulavarty wrote:
> > > Most of the issues you mention are null if you move the stats
> > > maintenance burden to userspace.
> > >
> > > The performance impact is also minimized since the hooks
> > > (read: overhead) can be loaded on-demand as needed.
> > >
> >
> > The overhead is - going through each mapping/inode in the system
> > and dumping out "nrpages" - to get per-file statistics. This is
> > going to be expensive, need locking and there is no single list
> > we can traverse to get it. I am not sure how to do this.
Can't you add hooks to add_to_page_cache/remove_from_page_cache
to record pagecache activity ?
> and worse... you're going to need memory to store the results, either in
> kernel or in userspace, and you don't know how much until you're done.
> That memory is going to need to be allocated, which in turn changes the
> vm state..
Indeed - need to pre-allocate some sensible amount of memory to store the
results (relayfs does it for your).
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Better pagecache statistics ?
Date: Thu, 1 Dec 2005 15:57:11 -0200 [thread overview]
Message-ID: <20051201175711.GA17169@dmt.cnet> (raw)
In-Reply-To: <1133457700.2853.78.camel@laptopd505.fenrus.org>
On Thu, Dec 01, 2005 at 06:21:39PM +0100, Arjan van de Ven wrote:
> On Thu, 2005-12-01 at 09:15 -0800, Badari Pulavarty wrote:
> > > Most of the issues you mention are null if you move the stats
> > > maintenance burden to userspace.
> > >
> > > The performance impact is also minimized since the hooks
> > > (read: overhead) can be loaded on-demand as needed.
> > >
> >
> > The overhead is - going through each mapping/inode in the system
> > and dumping out "nrpages" - to get per-file statistics. This is
> > going to be expensive, need locking and there is no single list
> > we can traverse to get it. I am not sure how to do this.
Can't you add hooks to add_to_page_cache/remove_from_page_cache
to record pagecache activity ?
> and worse... you're going to need memory to store the results, either in
> kernel or in userspace, and you don't know how much until you're done.
> That memory is going to need to be allocated, which in turn changes the
> vm state..
Indeed - need to pre-allocate some sensible amount of memory to store the
results (relayfs does it for your).
--
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 17:57 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 [this message]
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
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=20051201175711.GA17169@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=arjan@infradead.org \
--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.