Messages in this thread | | | Date | Thu, 19 Feb 2009 22:12:17 +0900 | Subject | Re: [PATCH] Add tracepoints to track pagecache transition | From | KOSAKI Motohiro <> |
| |
> 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?
>>> I attached an example which is visualization of pagecache status using >>> SystemTap. >> >> it seems no attached. and SystemTap isn't used kernel developer at all. >> I don't think it's enough explanation. >> Can you make seekwatcher liked completed comsumer program? >> (if you don't know seekwatcher, see http://oss.oracle.com/~mason/seekwatcher/) > > I understand a tracer using these tracepoints need to be implemented. > What I want to do is counting pagecache per file. We can retrieve inode > from mapping and count pagecache per inode in these tracepoints. > > >>> That graph describes pagecache transition of File A and File B >>> on a file-by-file basis with the situation where regular I/O to File A >>> is delayed because of other I/O to File B. >> >> If you want to see I/O activity, you need to add tracepoint into block layer. > > I think tracking pagecache is useful for understanding process I/O activity, > because whether process I/O completes by accessing memory or HDD is determined by > accessed files on pagecache or not.
I don't know your opinion is right or not. However, your opinion don't get consensus yet.
Perhaps, you need to make demonstrate programs, I think.
>> And, both function is freqentlly called one. >> I worry about performance issue. can you prove no degression? > > I will try to probe that.
Perhaps, this is not needed yet. Generally, worthless patch is never merged although it's no performance penalty. So, I think you should explain the patch worth at first :)
| |