Messages in this thread | | | Subject | Re: Is it a workqueue related issue in 2.6.37 (Was: Re: [libvirt] blkio cgroup [solved]) | From | Steven Rostedt <> | Date | Fri, 25 Feb 2011 21:47:40 -0500 |
| |
On Fri, 2011-02-25 at 15:18 -0500, Vivek Goyal wrote:
> Thanks Steve. In this case this feature of sending trace data over > network would have helped. We were running into issues where IO scheduler > was freezing so we could not read anything from disk(including saved traces). > Hence we were directing everything to console and then doing copy paste. > > So sending it over network would have probably worked even in this case. > > Will give trace-cmd a try next time.
Hi Vivek,
I just pushed out a hack that lets trace-cmd read the blktrace.
I found that the blktrace never exported its structure to the /debug/tracing/events/ftrace/blktrace/format. So userspace has no real way to know how to parse it.
Instead, I wrote a hack that creates this file semi dynamically, based on the information of other events. I also copied a lot of the blktrace code from the kernel so that it can print out the same format.
You need to install the plugin that is built with trace-cmd. It will either be automatically installed if you do a make install, but if you do not have root access, just cp the plugin_blk.so into ~/.trace-cmd/plugins directory (you may need to make that directory yourself). Then when you run trace-cmd report on a file made with the blk tracer, it will give you a nice output.
If you already have a trace.dat file from a previous extract, you don't need to run the trace again. The trace-cmd report will work on that file now.
I'll be heading out to NYC on Monday for the End Users Conf and this weekend I need to get all my chores done around the house for the misses to let me go ;) Thus, I wont be doing much more till I get back at the end of next week.
-- Steve
| |