From: Keiichi KII <k-keiichi@bx.jp.nec.com>
To: linux-kernel@vger.kernel.org
Cc: lwoodman@redhat.com, linux-mm@kvack.org, mingo@elte.hu,
tzanussi@gmail.com, riel@redhat.com, rostedt@goodmis.org,
akpm@linux-foundation.org, fweisbec@gmail.com,
Munehiro Ikeda <m-ikeda@ds.jp.nec.com>,
Atsushi Tsuji <a-tsuji@bk.jp.nec.com>
Subject: [RFC PATCH -tip 0/2 v2] pagecache tracepoints proposal
Date: Fri, 22 Jan 2010 19:04:16 -0500 [thread overview]
Message-ID: <4B5A3D00.8080901@bx.jp.nec.com> (raw)
Hello,
This is v2 of a patchset to add some tracepoints for pagecache.
I would propose several tracepoints for tracing pagecache behaviors and
a script for these.
By using both the tracepoints and the script, we can monitor pagecache usage
with high resolution. Example output of the script looks like:
[file list]
cached
device inode pages
--------------------------------
253:0 1051413 130
253:0 1051399 2
253:0 1051414 44
253:0 1051417 154
o postmaster-2330
cached added removed indirect
device inode pages pages pages removed pages
----------------------------------------------------------------
253:0 1051399 0 2 0 0
253:0 1051417 154 0 0 0
253:0 1051413 130 0 0 0
253:0 1051414 44 0 0 0
----------------------------------------------------------------
total: 337 2 0 0
We can now know system-wide pagecache usage by /proc/meminfo.
But we have no method to get higher resolution information like per file or
per process usage than system-wide one.
A process may share some pagecache or add a pagecache to the memory or
remove a pagecache from the memory.
If a pagecache miss hit ratio rises, maybe it leads to extra I/O and
affects system performance.
So, by using the tracepoints we can get the following information.
1. how many pagecaches each process has per each file
2. how many pages are cached per each file
3. how many pagecaches each process shares
4. how often each process adds/removes pagecache
5. how long a pagecache stays in the memory
6. pagecache hit rate per file
Especially, the monitoring pagecache usage per each file would help us tune
some applications like database.
Changelog since v1
o Add a script based on "perf trace stream scripting support".
Any comments are welcome.
--
Keiichi Kii <k-keiichi@bx.jp.nec.com>
--
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 reply other threads:[~2010-01-23 0:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-23 0:04 Keiichi KII [this message]
2010-01-23 0:07 ` [RFC PATCH -tip 1/2 v2] add tracepoints for pagecache Keiichi KII
2010-01-23 2:28 ` Steven Rostedt
2010-01-25 22:17 ` Keiichi KII
2010-01-23 0:08 ` [RFC PATCH -tip 2/2 v2] add a scripts for pagecache usage per process Keiichi KII
2010-01-23 8:21 ` Tom Zanussi
2010-01-25 22:16 ` Keiichi KII
2010-02-01 8:17 ` Tom Zanussi
2010-02-01 21:20 ` Keiichi KII
2010-02-23 17:54 ` Frederic Weisbecker
2010-02-23 18:13 ` Peter Zijlstra
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=4B5A3D00.8080901@bx.jp.nec.com \
--to=k-keiichi@bx.jp.nec.com \
--cc=a-tsuji@bk.jp.nec.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@redhat.com \
--cc=m-ikeda@ds.jp.nec.com \
--cc=mingo@elte.hu \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox