On Wed, 27 Sep 2006 23:22:02 +0200
"roland" <[email protected]> wrote:
> thanks. tried to contact redflag, but they don`t answer. maybe support is
> being on holiday.... !?
>
> linux kernel hackers - there is really no standard way to watch i/o metrics
> (bytes read/written) at process level?
The patch csa-accounting-taskstats-update.patch in current -mm kernels
(whcih is planned for 2.6.19) does have per-process chars-read and
chars-written accounting ("Extended accounting fields"). That's probably
not waht you really want, although it might tell you what you want to know.
> it`s extremly hard for the admin to track down, what process is hogging the
> disk - especially if there is more than one task consuming cpu.
Sure. Doing this is actually fairly tricky because disk writes are almost
always deferred. We'd need to remember which process dirtied some memory,
then track that info all the way down to the disk IO level, then perform
the accounting operations at IO submit-time or completion time, on a
per-page basis. It isn't rocket-science, but it's a lot of stuff and some
overhead.
> meanwhile i found blktrace and read into the documenation. looks really cool
> and seems to be very powerful tool - but it it`s seems a little bit
> "oversized" and not the right tool for this. seems to be for
> tracing/debugging/analysis
>
> what about http://lkml.org/lkml/2005/9/12/89 "with following patch,
> userspace processes/utilities will be able to access per process I/O
> statistics. for example, top like utilites can use this information" which
> has been posted to lkml one year ago ? any update on this ?
csa-accounting-taskstats-update.patch makes that information available to
userspace.
But it's approximate, because
- it doesn't account for disk readahead
- it doesn't account for pagefault-initiated reads (althought it easily
could - Jay?)
- it overaccounts for a process writing to an already-dirty page.
(We could fix this too: nuke the existing stuff and do
current->wchar += PAGE_CACHE_SIZE;
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)
hm. There's actually quite a lot we could do here to make these fields
more accurate and useful. A lot of this depends on what the definition of
these fields _is_. Is is just for disk IO? Is it supposed to include
console IO, or what?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
