All of lore.kernel.org
 help / color / mirror / Atom feed
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>

(2010年01月23日 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

WARNING: multiple messages have this Message-ID (diff)
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>

  reply	other threads:[~2010-01-25 22:19 UTC|newest]

Thread overview: 22+ 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:04 ` Keiichi KII
2010-01-23  0:07 ` [RFC PATCH -tip 1/2 v2] add tracepoints for pagecache Keiichi KII
2010-01-23  0:07   ` Keiichi KII
2010-01-23  2:28   ` Steven Rostedt
2010-01-23  2:28     ` Steven Rostedt
2010-01-25 22:17     ` Keiichi KII
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  0:08   ` Keiichi KII
2010-01-23  8:21   ` Tom Zanussi
2010-01-23  8:21     ` Tom Zanussi
2010-01-25 22:16     ` Keiichi KII [this message]
2010-01-25 22:16       ` Keiichi KII
2010-02-01  8:17       ` Tom Zanussi
2010-02-01  8:17         ` Tom Zanussi
2010-02-01 21:20         ` Keiichi KII
2010-02-01 21:20           ` Keiichi KII
2010-02-23 17:54         ` Frederic Weisbecker
2010-02-23 17:54           ` Frederic Weisbecker
2010-02-23 18:13           ` Peter Zijlstra
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 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.