From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC]degradation on IPF due to hypercall set irq Date: Wed, 22 Nov 2006 09:26:20 +0000 Message-ID: References: <51CFAB8CB6883745AE7B93B3E084EBE207DD53@pdsmsx412.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51CFAB8CB6883745AE7B93B3E084EBE207DD53@pdsmsx412.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Xu, Anthony" Cc: xen-devel@lists.xensource.com, xen-ia64-devel List-Id: xen-devel@lists.xenproject.org On 22/11/06 09:24, "Xu, Anthony" wrote: >>>> To clarify, by event/main loop I mean: Flush just before qemu blocks >>>> (otherwise multicall can be held for unbounded time, unless we set a >>>> batching timeout which hopefully we can avoid needing to do). > > Why otherwise multicall can be held for unbounded time? Qemu only wakes up for device-model accesses. We don't know when the next of those will be. So we should flush multicalls before the potentially blocking select(). -- Keir