[Virtio-fs] [RFC PATCH 0/2] add stat tools for virtiofsd

[Stefan Hajnoczi]

On Fri, Aug 23, 2019 at 10:57:43AM +0100, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefanha at redhat.com) wrote:
> > On Mon, Aug 19, 2019 at 11:41:12AM +0800, Gang Deng wrote:
> > > There exist two components: vtrace && vstat. vtrace is embeded in virtiofsd,
> > > it will put raw statistics data into share memory. Then the vstat tool could
> > > parse it and do some post processing works. The performance overhead of
> > > vtrace is very small because it does very simple things.
> > 
> > The QEMU source tree already contains support for DTrace/SystemTap,
> > LTTng Userspace Tracer, ftrace, and other tracers via tracetool.  See
> > docs/devel/tracing.txt and scripts/tracetool.py.
> > 
> > It would be good to use that tracing infrastructure instead of writing
> > tracing code from scratch.  Soon someone will want to record FUSE
> > request arguments and other information and then the trace file format
> > and code will become complex and duplicate what tracetool already does.
> > 
> > With tracetool all trace events are defined in a trace-events file
> > (contrib/virtiofsd/trace-events):
> > 
> >   virtiofs_op_begin(int opcode) "opcode 0x%x"
> >   virtiofs_op_end(int opcode, int64_t ns) "opcode 0x%x ns %" PRId64
> > 
> > It would be nice to capture more information: fuse_in_header->unique (to
> > identify the request) and fuse_in_header->nodeid (the inode).
> > 
> > The lowest overhead tracer that tracetool supports is LTTng UST (it uses
> > shared memory) and would be suitable for vstat.
> > 
> > Adding tracetool to virtiofsd will require a little work to verify it
> > works with your tracer of choice (e.g. LTTng UST) despite the process
> > sandboxing, but in the long term I don't think writing tracing code from
> > scratch again makes sense.
> 
> I'm used to using tracing as event logging; but how do they work for the
> type of measurement that Gang Deng is doing, where it's not really about
> logging each event; just being a place to hold some stats?

I think the approach in this patch series works better than tracing
would for this use case.  In the other sub-thread I've asked to avoid
using the "trace"/"tracing" to describe this feature.  This will prevent
confusion and reduces the temptation to grow this into yet another
tracer.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20190827/1e51a421/attachment.sig>