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