From: Keiichi KII <k-keiichi@bx.jp.nec.com>
To: Tom Zanussi <tzanussi@gmail.com>
Cc: linux-kernel@vger.kernel.org, lwoodman@redhat.com,
linux-mm@kvack.org, mingo@elte.hu, 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: Re: [RFC PATCH -tip 2/2 v2] add a scripts for pagecache usage per process
Date: Mon, 25 Jan 2010 17:16:53 -0500 [thread overview]
Message-ID: <4B5E1855.4090809@bx.jp.nec.com> (raw)
In-Reply-To: <1264234865.6595.75.camel@tropicana>
(2010a1'01ae??23ae?JPY 03:21), Tom Zanussi wrote:
> Hi,
>
> On Fri, 2010-01-22 at 19:08 -0500, Keiichi KII wrote:
>> The scripts are implemented based on the trace stream scripting support.
>> And the scripts implement the following.
>> - how many pagecaches each process has per each file
>> - how many pages are cached per each file
>> - how many pagecaches each process shares
>>
>
> Nice, it looks like a very useful script - I gave it a quick try and it
> seems to work well...
>
> The only problem I see, nothing to do with your script and nothing you
> can do anything about at the moment, is that the record step generates a
> huge amount of data, which of course makes the event processing take
> awhile. A lot of it appears to be due to perf itself - being able to
> filter out the perf-generated events in the kernel would make a big
> difference, I think; you normally don't want to see those anyway...
Yes, right. I don't want to process the data of perf itself.
I will try to find any way to solve this problem.
> BTW, I see that you did your first version in Python - not that you'd
> want to redo it again, but just FYI I now have working Python support
> that I'll be posting soon - I still have some small details to hammer
> out, but if you have any other scripts in the pipeline, in a couple days
> you'll be able to use Python instead if you want.
It will help me create some scripts. I will use Python support if it is posted.
>> To monitor pagecache usage per a process, run "pagecache-usage-record" to
>> record perf data for "pagecache-usage.pl" and run "pagecache-usage-report"
>> to display.
>
> Another way of course would be to use 'perf trace record/report' and the
> script name as shown by perf trace -l:
>
> $ perf trace record pagecache-usage
> $ perf trace report pagecache-usage
Thank you for your information.
I will use this way.
>> Index: linux-2.6-tip/tools/perf/scripts/perl/pagecache-usage.pl
>> ===================================================================
>> --- /dev/null
>> +++ linux-2.6-tip/tools/perf/scripts/perl/pagecache-usage.pl
>> @@ -0,0 +1,160 @@
>> +# perf trace event handlers, generated by perf trace -g perl
>
> You might want to get rid of this and add a short description and your
> name, if you want to take credit for it. ;-)
>
>> +# Licensed under the terms of the GNU GPL License version 2
>> +
>
>> +# The common_* event handler fields are the most useful fields common to
>> +# all events. They don't necessarily correspond to the 'common_*' fields
>> +# in the format files. Those fields not available as handler params can
>> +# be retrieved using Perl functions of the form common_*($context).
>> +# See Context.pm for the list of available functions.
>> +
>
> You can get rid of this part too - it's just meant to be helpful
> information generated when starting a script.
>
I'll remove unnecessary comments and add a short description next time.
>> +my %unhandled;
>> +
>> +sub trace_unhandled
>> +{
>> + my ($event_name, $context, $common_cpu, $common_secs, $common_nsecs,
>> + $common_pid, $common_comm) = @_;
>> +
>> + $unhandled{$event_name}++;
>> +}
>> +
>> +sub print_unhandled
>> +{
>> + if ((scalar keys %unhandled) == 0) {
>> + print "unhandled events nothing\n";
>
> This is kind of distracting - it's not too useful to know that you don't
> have unhandled events, but if you do have some, it is useful to print
> those as you do below - it points out that some event type are being
> unnecessarily recorded or the script is being run on the wrong trace
> data.
I don't have unhandled events to monitor pagecache usage as you say.
So I will remove these code.
Thanks,
Keiichi
--
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:[~2010-01-25 22:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-23 0:04 [RFC PATCH -tip 0/2 v2] pagecache tracepoints proposal Keiichi KII
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 [this message]
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=4B5E1855.4090809@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