From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] qemu-kvm: Consolidate kvm_eat_signals Date: Mon, 12 May 2008 14:56:33 +0300 Message-ID: <48283071.5030600@qumranet.com> References: <482820DC.6030509@web.de> <48282B16.7050006@qumranet.com> <48282D13.9060903@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Jan Kiszka Return-path: In-Reply-To: <48282D13.9060903@web.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Jan Kiszka wrote: >> Given that with the iothread we spend very little time processing >> signals in vcpu threads, maybe it's better to drop the loop completely. >> The common case is zero or one pending signals. The uncommon case of >> two or more pending signals will be handled by the KVM_RUN ioctl >> returning immediately with -EINTR (i.e. in the outer loop). >> >> > > You mean > > static void kvm_main_loop_wait(CPUState *env, int timeout) > { > pthread_mutex_unlock(&qemu_mutex); > kvm_eat_signal(env, timeout); > pthread_mutex_lock(&qemu_mutex); > cpu_single_env = env; > > vcpu_info[env->cpu_index].signalled = 0; > } > > ? > Yes. The loop was a (perhaps premature) optimization that is now totally unnecessary, unless I'm missing something quite large. Oh. There used to be a bug where we didn't check for a pending signal before the first guest entry, so this would add a lot of latency (effectively making the bug window much larger). That was only closed in 2.6.24 (by 7e66f350). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone