From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: assign-dev: Purpose of interrupt_work Date: Mon, 12 Oct 2009 11:40:59 +0200 Message-ID: <4AD2F9AB.90607@redhat.com> References: <4AD2DA57.6030006@web.de> <20091012074513.GV16702@redhat.com> <4AD2DFE2.4050406@web.de> <20091012075715.GW16702@redhat.com> <4AD2E5F8.4070107@web.de> <20091012083913.GX16702@redhat.com> <4AD2F117.7000403@web.de> <4AD2F37A.3060600@redhat.com> <4AD2F601.2050207@web.de> <4AD2F722.4030605@redhat.com> <20091012093831.GB16702@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm-devel To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:63071 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754838AbZJLJl1 (ORCPT ); Mon, 12 Oct 2009 05:41:27 -0400 In-Reply-To: <20091012093831.GB16702@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/12/2009 11:38 AM, Gleb Natapov wrote: > >> irqfd can work from interrupt context, so if we only use the >> workqueue for the many-vcpu cases, we should be fine. >> >> I think we can do it cleanly, too: in ioapic code, if we're talking >> to one vcpu, wake it immediately; otherwise schedule work to >> continue in process context. This was the common code can always >> work in interrupt context and not worry about the work queue. >> >> > Even if we are talking to one cpu locking is still needed, so unless we > make it spinlock we can't inject from irq context. If we change mutex to > spinlock what is the point of work queue? > Not to loop over 4096 vcpus with interrupts disabled, triggered by guest action. -- error compiling committee.c: too many arguments to function