From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9YkL-0003No-L8 for qemu-devel@nongnu.org; Fri, 30 Sep 2011 04:47:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9YkG-0001at-44 for qemu-devel@nongnu.org; Fri, 30 Sep 2011 04:47:05 -0400 Received: from thoth.sbs.de ([192.35.17.2]:27972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9YkF-0001aR-OT for qemu-devel@nongnu.org; Fri, 30 Sep 2011 04:47:00 -0400 Message-ID: <4E8581F7.2070300@siemens.com> Date: Fri, 30 Sep 2011 10:46:47 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20110930081849.GC4512@yookeroo.fritz.box> In-Reply-To: <20110930081849.GC4512@yookeroo.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Avoiding nographic_timer exits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: qemu-devel@nongnu.org On 2011-09-30 10:18, David Gibson wrote: > With PowerKVM, exits from KVM to qemu are even more expensive than on > x86. One significant source of these we're finding (since we usually > work in -nographic mode) is the nographic_timer. > > At present, we're using a hack to disable it, but that's obviously not > a long term solution. From examination, it looks like the only > purpose of this timer is to flush coalesced mmios. So it seems like > the timer should only be activated when a coalesced mmio region > actually exists, but I'm not entirely sure how to go about that. > > Thinking longer term, it seems very odd that a userspace periodic > timer handles this at all. Surely it would make more sense to use a > kernel timer within KVM, which can be activated only when there are > actually pending coalesced MMIOs in the buffer. Coalesced MMIO should only be flushed when a device depending on it gets accessed - either by a VCPU or by the iothread (to update the graphic output e.g.). We are working on such a concept (to reduce latency for VCPUs with real-time constraints). And long-term, we need per-device MMIO buffers to avoid flushing unrelated content. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux