Per process I/O (was Decorating a kernel function).

2007-02-21 Thread Tzahi Fadida
A bit of a followup from my previous question.
Are there already solutions to the per process I/O stats?
Not that my fun exercises into implementing a better block_dump would be 
commercial grade (but rather fun grade), however, this is what drove me to 
this when i was searching for just this tool for my thesis 1-2 years ago.

P.s. got the stub into my module to work by exporting a structure that 
includes a function pointer from the kernel and in the module attach the real 
function to the pointer in the kernel structure. Later this could be either 
committed to the kernel tree (AS IF :) ) or be replaced by jprobe.

-- 
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at 
http://members.lycos.co.uk/my2nis/spamwarning.html

To unsubscribe, 
send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]



Re: Per process I/O (was Decorating a kernel function).

2007-02-22 Thread Gilad Ben-Yossef

Tzahi Fadida wrote:

A bit of a followup from my previous question.
Are there already solutions to the per process I/O stats?


For reason already explained on this mailing list before, your request is 
meaningless.

The read/write etc. operation of a process translate very badly to real I/O ops.

Gilad

--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
Codefidence. A name you can trust(tm)
Web: http://codefidence.com  | SIP: [EMAIL PROTECTED]
IL: +972.3.7515563 ext. 201  | Fax:+972.3.7515503
US: +1.212.2026643 ext. 201  | Cel:   +972.52.8260388

"Compile your program. Run sync three times to honour
coders of old." -- glxtest README file

=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]



Re: Per process I/O (was Decorating a kernel function).

2007-02-22 Thread Tzahi Fadida
On Thursday 22 February 2007 14:51, Gilad Ben-Yossef wrote:
> Tzahi Fadida wrote:
> > A bit of a followup from my previous question.
> > Are there already solutions to the per process I/O stats?
>
> For reason already explained on this mailing list before, your request is
> meaningless.
>
> The read/write etc. operation of a process translate very badly to real I/O
> ops.

It may not be accurate from various reasons, namely, the I/O queue CFQ,etc...
which delays certain writes reads depending on the position of the head of the 
disk. In addition, dirtied buffers which are written to disk in unknown 
future time.
However, for the purposes of what most people needs this, it should do.
For example, most people are interested to know, what process is generating 
most/a lot of/not at all  I/O requests and they will be willing to take an 
estimate. For that it will suffice. Unless, of course, there is a facility in 
linux that does that, that i am unaware of.

>
> Gilad

-- 
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at 
http://members.lycos.co.uk/my2nis/spamwarning.html

To unsubscribe, 
send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]



Re: Per process I/O (was Decorating a kernel function).

2007-02-22 Thread Amos Shapira

On 23/02/07, Tzahi Fadida <[EMAIL PROTECTED]> wrote:


It may not be accurate from various reasons, namely, the I/O queue
CFQ,etc...
which delays certain writes reads depending on the position of the head of
the
disk. In addition, dirtied buffers which are written to disk in unknown
future time.
However, for the purposes of what most people needs this, it should do.
For example, most people are interested to know, what process is
generating
most/a lot of/not at all  I/O requests and they will be willing to take an
estimate. For that it will suffice. Unless, of course, there is a facility
in
linux that does that, that i am unaware of.



In addition - if I understand the theory then most inaccuracies will happen
because of multiple processes accessing the same files and/or re-writing
existing blocks in files. I'd expect most usage patterns to be outside this
criteria - you don't get many situations where multiple processes write to
the same file and overwrite each other's write requests in memory before
they reach the disk, do you?

getrusage(2) seems to return total IO done by processes, but it's only
available for the calling process or terminated children. I suppose this is
what the time(1) commands use.

Assuming the above (i.e. files are mostly not written concurrently by
multiple processes), maybe you can try to track write(2) system calls.
Mulli's old syscalltack (http://syscalltrack.sourceforge.net/) should have
been able to do this for you if it was still relevant for current kernels
(is it?)

"inotifywatch -m -r" could report changes to files and directories. It
doesn't report WHO changed the file but it might give you a pointer in the
right direction.

It looks like the most re-occurring questions on Linux forums so it's worth
to keep digging.

--Amos


Re: Per process I/O (was Decorating a kernel function).

2007-02-25 Thread Tzahi Fadida
On Friday 23 February 2007 02:11, Amos Shapira wrote:
> Assuming the above (i.e. files are mostly not written concurrently by
> multiple processes), maybe you can try to track write(2) system calls.
> Mulli's old syscalltack (http://syscalltrack.sourceforge.net/) should have
> been able to do this for you if it was still relevant for current kernels
> (is it?)

I wonder if it is still relevant? Can someone say what are the advantages of 
using (=after porting of course) syscalltrack in 2.6 kernel over existing 
solutions. Like, for example, debugging uml, using kprobes, etc...
In addition, i think that in 2.4 there was some kind of syscall table which 
was exported and which you could replace syscall functions, but in 2.6 they 
stopped this practice and made this technique obsolete if not highly 
difficult/impossible.

>
> --Amos

-- 
Regards,
Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at 
http://members.lycos.co.uk/my2nis/spamwarning.html

To unsubscribe, 
send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]