Messages in this thread | | | Date | Mon, 22 Sep 2008 16:50:16 -0400 | From | Masami Hiramatsu <> | Subject | Re: Unified tracing buffer |
| |
Peter Zijlstra wrote: > On Mon, 2008-09-22 at 09:29 -0700, Martin Bligh wrote: >>>> In conjunction with the previous email on this thread >>>> (http://lkml.org/lkml/2008/9/22/160), may I suggest >>>> the equivalent interfaces in -mm tree (2.6.27-rc5-mm1) to be: >>>> >>>> relay_printk(<some struct with default filenames/pathnames>, <string>, >>>> ....) ; >>>> relay_dump(<some struct with default filenames/pathnames>, <binary >>>> data>); >>>> and >>>> relay_cleanup_all(<the struct name>); - Single interface that cleans up >>>> all files/directories/output data created under a logical entity. >>> Dude, relayfs is such a bad performing mess that extending it seems like >>> a bad idea. Better to write something new and delete everything relayfs >>> related. >> There did seem to be pretty universal agreement that we'd rather not >> use relayfs. >> >>> Also, it seems prudent to separate the ring-buffer implementation from >>> the event encoding/decoding facilities. >> Right - in conversation I had with Mathieu later, he suggested cleaning up >> relayfs - I fear this will delay us far too long, and get bogged down. >> If we can get one clean circular buffer implementation, then both >> relayfs and the tracing could share that common solution, > > Currently only blktrace and kvmtrace use relayfs, and I've heard people > talk about converting both to use lttng/ftrace infrastructure. At which > point relayfs is orphaned and ready for removal.
Hi Peter, Systemtap is still a heavy user of relayfs. :-) Anyway, if new buffering mechanism is enough for us, I think we're happy to move on it.
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |