From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56443 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTC48-0002wN-G9 for qemu-devel@nongnu.org; Thu, 16 Dec 2010 06:32:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PTC46-0004v5-5h for qemu-devel@nongnu.org; Thu, 16 Dec 2010 06:32:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28779) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PTC45-0004uy-Ty for qemu-devel@nongnu.org; Thu, 16 Dec 2010 06:32:06 -0500 Date: Thu, 16 Dec 2010 09:31:59 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [Qestion] What status of memory stats feature Message-ID: <20101216093159.086048ae@doriath> In-Reply-To: <1292453883.5097.9.camel@aglitke> References: <20101215162005.fdbc60b0.oomichi@mxs.nes.nec.co.jp> <20101215153927.1cd4690e@doriath> <1292453883.5097.9.camel@aglitke> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: Ken'ichi Ohmichi , Minoru Usui , qemu-devel@nongnu.org On Wed, 15 Dec 2010 16:58:03 -0600 Adam Litke wrote: > On Wed, 2010-12-15 at 15:39 -0200, Luiz Capitulino wrote: > > On Wed, 15 Dec 2010 16:20:05 +0900 > > "Ken'ichi Ohmichi" wrote: > > > > > > > > Hi, > > > > > > I tried to get the memory stats by using virDomainMemoryStats() of libvirt, > > > but it could not do it because of the following patch: > > > > > > [PATCH 03/23] disable guest-provided stats on "info balloon" command > > > 2010/10/01 from Luiz Capitulino > > > http://www.mail-archive.com/qemu-devel@nongnu.org/msg43024.html > > > > > > According to the related thread, the above patch avoids hanging user > > > monitor, and people hope the memory stats feature will be able in the > > > future. So I'd like to know the status of this feature. > > > > > > Is there the patch for enabling the feature ? > > > If the patch exists, I'd like to try it. > > > > It doesn't, afaik. > > It depends on what you are looking to do. If you just want to play > around and aren't concerned about lockups, You could undo the above > patch to re-enable the interface (although I cannot guarantee that even > this will work). > > > > What is the essential problem ? > > > > There are two essential problems here. > > > > The first one is that QMP lacks true asynchronous command support (it does > > have some code for it, but it's incomplete). > > I was never completely clear on the problems with the QMP async support. > > > The second problem is that we must not make an existing synchronous command > > asynchronous, because this breaks the ABI. > > The memory stats interface has always advertised itself as an async > command so this one shouldn't matter. Whether those semantics actually > ever worked is another issue. The query-balloon command used to be synchronous (or quite fast, or would never lockup). We changed that. > > > Does some infinite loop happen ? > > > > No, the guest doesn't respond. > > > > > Unfortunately, I cannot understand the cause of hanging user monitor. > > > > The balloon command needs guest cooperation (ie. it talks to the guest), > > if the guest doesn't respond the command will never return. > > Isn't that only a problem for the user monitor? For QMP you might just > never get a response to the stats request. IIRC, the QMP monitor is > never 'suspended' in the same way that the user monitor is so I wouldn't > expect it to be susceptible to the same lockup issues. We need to have a way to cancel the request. This is not the cause of this problem, though. > > We don't have a precise ETA for async support, but if it depends only on > > the new error framework work, then we could have it for 0.15. If it depends > > on the full monitor redesign work, then I guess we'll two releases. > > I can't provide a definitive answer to this unfortunately since I > haven't looked in awhile (nor am I privy to the details of the full > monitor redesign proposal. Basically, we're splitting HMP and QMP. The end result will be that HMP will use QMP as a C library. Not hard to do, but there's lots of code churn involved. Now, regarding async support, I already have a proposal, but I'll send it only next year because I'll be in vacations for two weeks.