* [Bug tapsets/6457] Provide I/O traces for iogrind
[not found] <20080425113103.6457.mark@klomp.org>
@ 2008-04-25 12:55 ` mark at klomp dot org
2008-04-25 14:26 ` michael dot meeks at novell dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: mark at klomp dot org @ 2008-04-25 12:55 UTC (permalink / raw)
To: systemtap
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|frysk-bugzilla at sourceware|systemtap at sources dot
|dot org |redhat dot com
Status|NEW |ASSIGNED
Component|general |tapsets
Product|frysk |systemtap
http://sourceware.org/bugzilla/show_bug.cgi?id=6457
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug tapsets/6457] Provide I/O traces for iogrind
[not found] <20080425113103.6457.mark@klomp.org>
2008-04-25 12:55 ` [Bug tapsets/6457] Provide I/O traces for iogrind mark at klomp dot org
@ 2008-04-25 14:26 ` michael dot meeks at novell dot com
2008-04-25 23:00 ` michael dot meeks at novell dot com
2008-04-25 23:14 ` fche at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: michael dot meeks at novell dot com @ 2008-04-25 14:26 UTC (permalink / raw)
To: systemtap
------- Additional Comments From michael dot meeks at novell dot com 2008-04-25 12:02 -------
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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6457
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug tapsets/6457] Provide I/O traces for iogrind
[not found] <20080425113103.6457.mark@klomp.org>
2008-04-25 12:55 ` [Bug tapsets/6457] Provide I/O traces for iogrind mark at klomp dot org
2008-04-25 14:26 ` michael dot meeks at novell dot com
@ 2008-04-25 23:00 ` michael dot meeks at novell dot com
2008-04-25 23:14 ` fche at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: michael dot meeks at novell dot com @ 2008-04-25 23:00 UTC (permalink / raw)
To: systemtap
------- Additional Comments From michael dot meeks at novell dot com 2008-04-25 12:05 -------
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 :-)
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6457
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug tapsets/6457] Provide I/O traces for iogrind
[not found] <20080425113103.6457.mark@klomp.org>
` (2 preceding siblings ...)
2008-04-25 23:00 ` michael dot meeks at novell dot com
@ 2008-04-25 23:14 ` fche at redhat dot com
3 siblings, 0 replies; 5+ messages in thread
From: fche at redhat dot com @ 2008-04-25 23:14 UTC (permalink / raw)
To: systemtap
------- Additional Comments From fche at redhat dot com 2008-04-25 12:55 -------
> 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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6457
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 5+ messages in thread