[lkml]   [2006]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: I/O statistics per process

didn`t discover that there is anything new about this (andrew? jay?) or if
some other person sent a patch , but i`d like to report that i came across a
really nice tool which would immediately benefit from per-process i/o
statistics feature.

please - this mail is not meant to clamor for such feature - it`s just to
show up some more benefits if this feature would exist.

vmktree at is some really nice monitoring tool being
able to graph performance statistics for a host running vmware virtual
machines (closed source - evil - i know ;) - and it can break that
statistics down to each virtual machine.

what`s hurting mostly here is that you have no clue how much I/O each of
those virtual machine is generating - you may give sort of a "guess" that a
machine with 100% idle cpu will not generate any significant amount of I/O,
but vmktree would be so much more powerful with a per-process I/O statistic,
since you can use your systems more efficient, because you would know about
you I/O hogs, too.

having the ability to take such information from /proc would be a real
killer feature - good for troubleshooting and also good for getting
important statistics!


this is another person, desperately seeking for a tool providing that

----- Original Message -----
From: "Andrew Morton" <>
To: "Jay Lan" <>
Cc: "roland" <>; "Fengguang Wu" <>;
<>; <>
Sent: Thursday, September 28, 2006 11:14 PM
Subject: Re: I/O statistics per process

> On Thu, 28 Sep 2006 15:00:17 -0700
> Jay Lan <> wrote:
>> >>> in __set_page_dirty_[no]buffers().) (But that ends up being wrong
>> >>> if
>> >>> someone truncates the file before it got written)
>> >>>
>> >>> - it doesn't account for file readahead (although it easily could)
>> >>>
>> >>> - it doesn't account for pagefault-initiated readahead (it could)
>> >>>
>> Mmm, i am not a true FS I/O person. The data collection patches i
>> submitted in Nov 2004 was the code i inherited and has been
>> used in production system by our CSA customers. We lost a bit in
>> contents and accuracy when CSA was ported from IRIX to Linux. I am
>> sure there is room for improvement without much overhead.
> OK, well it sounds like we're free to define these in any way we like. So
> we actually get to make them mean something useful - how nice.
> I hereby declare: "approxmiately equal to the number of filesystem bytes
> which this task has caused to occur, or which shall occur in the near
> future".
>> Maybe FS
>> I/O guys can chip in?
> I used to be one of them. I can take a look at doing this. Given the
> lack
> of any applciation to read the darn numbers out I guess I'll need to
> expose
> them in /proc for now. Yes, that monitoring patch (and an application to
> read from it!) would be appreciated, thanks.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-08 01:13    [W:0.047 / U:8.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site