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:47:59 +0000 Message-ID: References: <51CFAB8CB6883745AE7B93B3E084EBE207DD54@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: <51CFAB8CB6883745AE7B93B3E084EBE207DD54@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" , Keir Fraser Cc: xen-devel@lists.xensource.com, xen-ia64-devel List-Id: xen-devel@lists.xenproject.org On 22/11/06 09:38, "Xu, Anthony" wrote: > There are two threads, one is qemu thread, the other is IDE DMA thread, > In IDE DMA thread, when it finishing DMA opereration, it will set irq, but it > doesn't try to wakeup qemu thread. So if qemu thread is sleeping at the same > time, > this interrupt may be delivered until qemu thread wakes up, the time may be > 10 msec. > So we need a mechanism for IDE DMA thread to wake up Qemu thread. > > What's your opinion? Did the IDE code really need to made multithreaded? I suppose it's a better model for the stub domain plans... Anyway, it's a pain here because it will require the shadow wire bitmap to be updated with atomic accesses and the multicall state to be per-thread or to be protected with a mutex. Each thread should flush multicall state before it blocks. -- Keir