From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6ys-0002gO-EV for qemu-devel@nongnu.org; Thu, 10 Sep 2015 14:53:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za6yo-0003nR-El for qemu-devel@nongnu.org; Thu, 10 Sep 2015 14:53:58 -0400 Received: from mx2.parallels.com ([199.115.105.18]:38535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za6yo-0003nE-9e for qemu-devel@nongnu.org; Thu, 10 Sep 2015 14:53:54 -0400 References: <1441699228-25767-1-git-send-email-den@openvz.org> <1441699228-25767-6-git-send-email-den@openvz.org> <55EF0AB4.6090906@redhat.com> <55EF0C41.20308@redhat.com> From: "Denis V. Lunev" Message-ID: <55F1D1B7.5050107@openvz.org> Date: Thu, 10 Sep 2015 21:53:43 +0300 MIME-Version: 1.0 In-Reply-To: <55EF0C41.20308@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/5] disk_deadlines: add info disk-deadlines option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , qemu-devel@nongnu.org, Markus Armbruster , Raushaniya Maksudova , Luiz Capitulino , Stefan Hajnoczi On 09/08/2015 07:26 PM, Eric Blake wrote: > On 09/08/2015 10:20 AM, Eric Blake wrote: >> On 09/08/2015 02:00 AM, Denis V. Lunev wrote: >>> From: Raushaniya Maksudova >>> >>> This patch adds "info disk-deadlines" qemu-monitor option that prints >>> dump of all disk requests which caused a disk deadline in Guest OS >>> from the very start of Virtual Machine: >>> >> qapi interface review only: >> >> Should it be possible to filter to deadlines missed for a specific node, >> by having an arguments with an optional node name? >> >> Should any of the existing query-block or similar commands be modified >> to make it obvious that there are missed deadline stats, and that it >> would be useful to call query-disk-deadlines to learn more about them? > Also, should there be an event raised when a timeout occurs, so that > management doesn't have to poll this API? > ok, this seems a nice addition