iogrind is a prototype I/O profiling tool. http://live.gnome.org/iogrind It aims to give a fairly accurate picture of all the I/O your application would perform on a cold start. It has three parts: 1. tracing the application using valgrind 2. snapshotting the filesystem 3. simulating the trace, against a snapshot to visualise. It would be nice to provide the first part as a systemtap script. It would basically need to provide a trace of all file accesses (open, stat, chmod, unlink, ...) + all 1st time memory page touches.
This would be cool. One of the (two) biggest problems with iogrind currently is that it requires running valgrind on the application to collect it's data: this makes it incredibly slow - and difficult to use for complicated scenarios. What I'd like is something fast we can use to generate a trace for a whole system install - such that, we can subsequently re-run the install through a cut-down kernel very quickly with a tweaked file-system layout algorithm, and see what effect that has on various common operations. ie. real, repeatable, wide-scale performance regression testing for kernel file-systems. What I really need to see (beyond what strace can show (ie. all I/O relevant syscalls)) is first touches of memory mapped pages: both reads and writes. Would be wonderful if we could have that. There is an existing (somewhat lame) logging syntax used in iogrind, seen in the tests/ directory - but that's easy to tweak later: I just need the know-how to create the hooks. Thanks.
Another use-case; I'd love to be able to chase bugs like this: http://bugzilla.kernel.org/show_bug.cgi?id=7372 with a real-world trace, a cut-down Linux kernel, and simulated hardware :-)
> What I really need to see (beyond what strace can show (ie. all I/O relevant > syscalls)) is first touches of memory mapped pages: both reads and writes. Ah, this is why you needed to use valgrind. I don't think we can do exactly that from systemtap yet, since that would require active interference with process memory mappings. Maybe we need a utrace extension & event source for just that -- "touched a page for the first time". Until then, we can probably intercept the kernel's response to these occurrences: a page fault, or a dirty page writeout.
I was able to get iogrind running on Fedora 15 using the git repo: http://www.gnome.org/~michael/git/iogrind.git The last change to iogrind was in March 2010; there doesn't seem to be much activity on it. iogrind needs various mono packages to build and run including (available in Fedora, but not in RHEL6): gtk-sharp2-devel Able to get plots from the examples in the tests directory. However, things seem pretty fragile. Get lots of output like the following: ARGH - broken sect numbers in 'scribble' need fixing ARGH - broken sect numbers in 'scribble' need fixing ARGH - broken sect numbers in 'scribble' need fixing And iogrind crashes when switched to the scribble mode. The main point of getting a local version of iogrind working is to be able to tests out any output from a systemtap script.
no recent interest