lkml.org 
[lkml]   [2012]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Re: Re: [RFC PATCH 0/6] virtio-trace: Support virtio-trace
    Hi Amit,

    Sorry for the late reply.

    (2012/07/27 18:43), Amit Shah wrote:
    > On (Fri) 27 Jul 2012 [17:55:11], Yoshihiro YUNOMAE wrote:
    >> Hi Amit,
    >>
    >> Thank you for commenting on our work.
    >>
    >> (2012/07/26 20:35), Amit Shah wrote:
    >>> On (Tue) 24 Jul 2012 [11:36:57], Yoshihiro YUNOMAE wrote:
    >>

    [...]

    >>>>
    >>>> ***Just enhancement ideas***
    >>>> - Support for trace-cmd
    >>>> - Support for 9pfs protocol
    >>>> - Support for non-blocking mode in QEMU
    >>>
    >>> There were patches long back (by me) to make chardevs non-blocking but
    >>> they didn't make it upstream. Fedora carries them, if you want to try
    >>> out. Though we want to converge on a reasonable solution that's
    >>> acceptable upstream as well. Just that no one's working on it
    >>> currently. Any help here will be appreciated.
    >>
    >> Thanks! In this case, since a guest will stop to run when host reads
    >> trace data of the guest, char device is needed to add a non-blocking
    >> mode. I'll read your patch series. Is the latest version 8?
    >> http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg00035.html
    >
    > I suppose the latest version on-list is what you quote above. The
    > objections to the patch series are mentioned in Anthony's mails.

    I'll check the mails.

    > Hans maintains a rebased version of the patches in his tree at
    >
    > http://cgit.freedesktop.org/~jwrdegoede/qemu/
    >
    > those patches are included in Fedora's qemu-kvm, so you can try that
    > out if it improves performance for you.

    Thanks. I'll check those patches.

    >>>> - Make "vhost-serial"
    >>>
    >>> I need to understand a) why it's perf-critical, and b) why should the
    >>> host be involved at all, to comment on these.
    >>
    >> a) To make collecting overhead decrease for application on a guest.
    >> (see above)
    >> b) Trace data of host kernel is not involved even if we introduce this
    >> patch set.
    >
    > I see, so you suggested vhost-serial only because you saw the guest
    > stopping problem due to the absence of non-blocking code? If so, it
    > now makes sense. I don't think we need vhost-serial in any way yet.

    I understood. We suggested vhost-serial as one of the ideas for
    improving performances. Other features(trace-cmd, 9pfs, and
    non-blocking chardev) should be supported first, I think.

    > BTW where do you parse the trace data obtained from guests? On a
    > remote host?

    It is the best that we can parse the data on a remote host in this
    tracing system. Existing trace-cmd can already parse it on a remote
    site. If we add the feature collecting event-format data(guest's
    debugfs has that) from guests, we can parse tracing data on a remote
    host as well as on a host running guests.

    Thank you,

    --
    Yoshihiro YUNOMAE
    Software Platform Research Dept. Linux Technology Center
    Hitachi, Ltd., Yokohama Research Laboratory
    E-mail: yoshihiro.yunomae.ez@hitachi.com




    \
     
     \ /
      Last update: 2012-07-31 03:41    [W:0.028 / U:123.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site