Messages in this thread | | | Subject | Re: [PATCH] Add tracepoints to track pagecache transition | From | Lee Schermerhorn <> | Date | Thu, 19 Feb 2009 09:21:31 -0500 |
| |
On Thu, 2009-02-19 at 22:12 +0900, KOSAKI Motohiro wrote: > > Hi Kosaki-san, > > > > Thank you for your comment. > > > > KOSAKI Motohiro wrote: > >> Hi > >> > >> > >> In my 1st impression, this patch description is a bit strange. > >> > >>> The below patch adds instrumentation for pagecache. > >>> > >>> I thought it would be useful to trace pagecache behavior for problem > >>> analysis (performance bottlenecks, behavior differences between stable > >>> time and trouble time). > >>> > >>> By using those tracepoints, we can describe and visualize pagecache > >>> transition (file-by-file basis) in kernel and pagecache > >>> consumes most of the memory in running system and pagecache hit rate > >>> and writeback behavior will influence system load and performance. > >> > >> Why do you think this tracepoint describe pagecache hit rate? > >> and, why describe writeback behavior? > > > > I mean, we can describe file-by-file basis pagecache usage by using > > these tracepoints and it is important for analyzing process I/O behavior. > > More confusing. > Your page cache tracepoint don't have any per-process information. > > > > Currently, we can understand the amount of pagecache from "Cached" > > in /proc/meminfo. So I'd like to understand which files are using pagecache. > > There is one meta question, Why do you think file-by-file pagecache > infomartion is valueable? >
One might take a look at Marcello Tosatti's old 'vmtrace' patch. It contains it's own data store/transport via relayfs, but the trace points could be ported to the current kernel tracing infrastructure.
Here's a starting point: http://linux-mm.org/VmTrace
Quoting from that page:
>From the previous email to linux-mm: >"The sequence of pages which a given process or workload accesses >during its lifetime, a.k.a. "reference trace", is very important >information. It has been used in the past for comparison of page >replacement algorithms and other optimizations..."
Lee
| |