RE: Fwd: Systemtap support for disk i/o per pid

RE: Fwd: Systemtap support for disk i/o per pid

[Nguyen, Thang P]

As for disk I/O, currently I am also adding more hooks into ioscheduler
tapset to track disk activities such as block I/O location and estimate
disk seek time.  Li, I can send you what I have, and see where to fit
(or perhaps consolidate) them if necessary.

Thang

-----Original Message-----
From: systemtap-owner@sourceware.org
[mailto:systemtap-owner@sourceware.org] On Behalf Of Li Guanglei
Sent: Sunday, May 28, 2006 11:39 PM
To: James Dickens
Cc: systemtap@sourceware.org
Subject: Re: Fwd: Systemtap support for disk i/o per pid

James Dickens ??:
> resending due to improper mime type on the original
> 
> it would be simpler in most cases to probe syscalls that are easily
> trackable to pid's though this won't give a totally accurate of IO
> because of caching, but it is the easiest, and safest. When you go to
> lower level kernel interfaces it becomes difficult to attiribute
> actions with the pid that caused them.
> 
> James Dickens
> uadmin.blogspot.com

Currently Systemtap could make you able to trace all syscalls by pid,
e.g:
   stap -e "probe addevent.syscall {} " -x pid
to trace both entry & return of all syscalls
or:
   stap -e "probe addevent.syscall {}" -c command

I am getting started with Jose to implement new hooks about IO system 
calls which could give more details other than the syscall name. And 
we are also trying to map systemcall to the io scheduler and scsi hooks.

- Li Guanglei

Re: Fwd: Systemtap support for disk i/o per pid

[Li Guanglei]

Nguyen, Thang P ??:
> As for disk I/O, currently I am also adding more hooks into ioscheduler
> tapset to track disk activities such as block I/O location and estimate
> disk seek time.  Li, I can send you what I have, and see where to fit
> (or perhaps consolidate) them if necessary.

Great. I read your codes, it looks good but I have one comment. I 
think ioscheduler may not be a suitable category for submit_bio and 
other alias definitions like disk activities. I think we should define 
new stap files and alias categories for these probes. Do you think so?

I also copied this mail to Jose Santos since he is also the one doing 
LKET work with me.

- Guanglei

> 
> Thang
> 
> -----Original Message-----
> From: systemtap-owner@sourceware.org
> [mailto:systemtap-owner@sourceware.org] On Behalf Of Li Guanglei
> Sent: Sunday, May 28, 2006 11:39 PM
> To: James Dickens
> Cc: systemtap@sourceware.org
> Subject: Re: Fwd: Systemtap support for disk i/o per pid
> 
> James Dickens ??:
>> resending due to improper mime type on the original
>>
>> it would be simpler in most cases to probe syscalls that are easily
>> trackable to pid's though this won't give a totally accurate of IO
>> because of caching, but it is the easiest, and safest. When you go to
>> lower level kernel interfaces it becomes difficult to attiribute
>> actions with the pid that caused them.
>>
>> James Dickens
>> uadmin.blogspot.com
> 
> Currently Systemtap could make you able to trace all syscalls by pid,
> e.g:
>    stap -e "probe addevent.syscall {} " -x pid
> to trace both entry & return of all syscalls
> or:
>    stap -e "probe addevent.syscall {}" -c command
> 
> I am getting started with Jose to implement new hooks about IO system 
> calls which could give more details other than the syscall name. And 
> we are also trying to map systemcall to the io scheduler and scsi hooks.
> 
> - Li Guanglei

Re: Fwd: Systemtap support for disk i/o per pid

[Li Guanglei]

James Dickens ??:
> resending due to improper mime type on the original
> 
> it would be simpler in most cases to probe syscalls that are easily
> trackable to pid's though this won't give a totally accurate of IO
> because of caching, but it is the easiest, and safest. When you go to
> lower level kernel interfaces it becomes difficult to attiribute
> actions with the pid that caused them.
> 
> James Dickens
> uadmin.blogspot.com

Currently Systemtap could make you able to trace all syscalls by pid, e.g:
   stap -e "probe addevent.syscall {} " -x pid
to trace both entry & return of all syscalls
or:
   stap -e "probe addevent.syscall {}" -c command

I am getting started with Jose to implement new hooks about IO system 
calls which could give more details other than the syscall name. And 
we are also trying to map systemcall to the io scheduler and scsi hooks.

- Li Guanglei

Fwd: Systemtap support for disk i/o per pid

[James Dickens]

resending due to improper mime type on the original


---------- Forwarded message ----------
From: James Dickens <jamesd.wi@gmail.com>
Date: May 28, 2006 2:08 PM
Subject: Re: Systemtap support for disk i/o per pid
To: Li Guanglei <guanglei@cn.ibm.com>
Cc: R Blundell <rickb@rapidvps.com>, systemtap@sourceware.org



On 5/27/06, Li Guanglei <guanglei@cn.ibm.com> wrote:
>  R Blundell ??:
> > Hello, this is my first post to the mailing list. Does or will systemtap
> > support "per pid" disk i/o accounting/details?  I could not find any
> > mention of this specifically on the website, papers, etc.
> >
> > Thank you
> > Rick
> Currently systemtap could be able to trace the io scheduler activities
> and scsi activities. You could use "man lket" to get more details.
>
> Some event hooks in these two categories could be filtered by pid. But
>   you can just trace all of them and later filter by pid in user space.
>
>

it would be simpler in most cases to probe syscalls that are easily
trackable to pid's though this won't give a totally accurate of IO
because of caching, but it is the easiest, and safest. When you go to
lower level kernel interfaces it becomes difficult to attiribute
actions with the pid that caused them.

 James Dickens
 uadmin.blogspot.com