Re: Per process I/O (was Decorating a kernel function).
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]
Re: Per process I/O (was Decorating a kernel function).
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).
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).
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]
Per process I/O (was Decorating a kernel function).
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]