From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boWDK-00010b-OJ for qemu-devel@nongnu.org; Mon, 26 Sep 2016 09:45:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1boWDI-00069H-NF for qemu-devel@nongnu.org; Mon, 26 Sep 2016 09:44:57 -0400 Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]:36290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boWDI-00063o-GA for qemu-devel@nongnu.org; Mon, 26 Sep 2016 09:44:56 -0400 Received: by mail-it0-x22f.google.com with SMTP id u134so11127133itb.1 for ; Mon, 26 Sep 2016 06:44:34 -0700 (PDT) MIME-Version: 1.0 From: prashanth sunder Date: Mon, 26 Sep 2016 19:14:33 +0530 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] top(1) utility implementation in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 Approach 2) Using Trace: Add trace event for each type of event loop resource (timer, fd, bh, etc) in order to see when a resource fires. Write top(1)-like SystemTap script to get data from the trace backend. Pros: No performance overhead using trace Cons: The data available from trace depends on the trace-backend that qemu is configured with. It is dependent on availability of SystemTap and is backend specific Approach 3) Use Trace and extract trace backend data through QMP Pros: No performance overhead using trace Cons: User has to configure QMP to point to the trace backend. Please let me know which implementation it is that I should follow and work on. If I've missed out on anything important. Please add those points to this mail. Regards, Prashanth Sunder