From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqJAB-0003MT-Ca for qemu-devel@nongnu.org; Sat, 01 Oct 2016 08:13:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqJA5-0004bO-A7 for qemu-devel@nongnu.org; Sat, 01 Oct 2016 08:13:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqJA5-0004b4-1E for qemu-devel@nongnu.org; Sat, 01 Oct 2016 08:13:01 -0400 Date: Sat, 1 Oct 2016 20:12:56 +0800 From: Fam Zheng Message-ID: <20161001121043.GA26716@lemon> References: <20160926162846.GL18393@redhat.com> <20160929024530.GC6412@lemon> <874m4xmi29.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874m4xmi29.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] top(1) utility implementation in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: prashanth sunder , qemu-devel@nongnu.org On Fri, 09/30 19:08, Markus Armbruster wrote: > Fam Zheng writes: > > > On Mon, 09/26 17:28, Daniel P. Berrange wrote: > >> On Mon, Sep 26, 2016 at 07:14:33PM +0530, prashanth sunder wrote: > >> > Hi All, > >> > > >> > Summary of the discussion and different approaches we had on IRC > >> > regarding a top(1) tool in qemu > >> > > >> > Implement unique naming for all event loop resources. Sometimes a > >> > string literal can be used but other times the unique name needs to be > >> > generated at runtime (e.g. filename for an fd). > >> > > >> > Approach 1) > >> > For a built-in QMP implementation: > >> > We have callbacks from fds, BHs and Timers > >> > So everytime one of them is registered - we add them to the list(what > >> > we see through QMP) > >> > and when they are unregistered - we remove them from the list. > >> > Ex: aio_set_fd_handler(fd, NULL, NULL, NULL) - unregistering an fd - > >> > will remove the fd from the list. > >> > > >> > QMP API: > >> > set-event-loop-profiling enable=on/off > >> > [interval=seconds] [iothread=name] and it emits a QMP event with > >> > [{name, counter, time_elapsed}] > >> > > >> > Pros: > >> > It works on all systems. > >> > Cons: > >> > Information present inside glib is exposed only via systemtap tracing > >> > - these will not be available via QMP. > >> > For example - I/O in chardevs, network IO etc > >> > >> > >> There's other downsides to QMP approach > >> > >> - Emitting data via QMP will change the behaviour of the system > >> itself, since QMP will trigger usage of the main event loop > >> which is the thing being traced. The degree of disturbance > >> will depend on the interval for emitting events > > > > Yes, but compared to a guest that is busy enough to be analyzed with qemu-top, > > I don't think this can be a high degree, even it's at a few events per second. > > > >> > >> - If the interval is small and you're monitoring more than one > >> guest at a time, then the overhead of QMP could start to get > >> quite significant across the host as a whole. This was > >> mentioned at the summit wrt existing I/O stats expose by > >> QEMU for block / net device backends. > > > > qemu-top is supposed to run only in foreground when human attends. So I'm not > > concerned about the system wide overall overhead. > > > >> > >> - The 'top' tool does not actually have direct access to > >> QMP for any libvirt guests and we've unlikely to want to > >> expose such QMP events via libvirt in any kind of supported > >> API, as they're very use-case specific in design. So at best > >> the app would have to use libvirt QMP passthrough which is > >> acceptable for developer / test environments, but not > >> something that's satisfactory for production deployments. > > > > Just another idea: my original though on how to send statistics to 'qemu-top', > > was a specialized channel like a socket with a minimized protocol (e.g. a > > mini-QMP, with only whitelisted commands, or an event-only QMP, or simply in an > > ad-hoc format). > > What's the advantage over simply using another QMP monitor? Naturally, > injecting arbitrary QMP commands behind libvirt's back isn't going to > end well, but "don't do that then". Information queries and listening > to events should be safe. In order to avoid a Libvirt "tainted" state at production env, of course assuming qemu-top is useful there at all. > Note that we could have a QMP command to spawn monitors. Fun! Cool, and how hard is it to implement a QMP command to kill monitors? :) Fam