From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REhAh-0008MD-VQ for qemu-devel@nongnu.org; Fri, 14 Oct 2011 08:47:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1REhAh-0004en-01 for qemu-devel@nongnu.org; Fri, 14 Oct 2011 08:47:31 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:54393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REhAg-0004eh-Ql for qemu-devel@nongnu.org; Fri, 14 Oct 2011 08:47:30 -0400 Received: by wwf10 with SMTP id 10so1588605wwf.4 for ; Fri, 14 Oct 2011 05:47:29 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E982F5D.40801@redhat.com> Date: Fri, 14 Oct 2011 14:47:25 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1318436475-20691-1-git-send-email-peter.maydell@linaro.org> <4E96F51A.8080200@suse.de> <4E9764D7.5020103@web.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] configure: Detect when glibc implements makecontext() to always fail List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , patches@linaro.org, Anthony Liguori , qemu-devel@nongnu.org On 10/14/2011 02:30 PM, Peter Maydell wrote: > I've also just discovered that it's no use on Oneiric, > where the linker warning has gone away but the syscall > still always returns ENOSYS. > > I think we should just always use the gthread implementation > rather than preferring a non-portable-and-hard-to-detect > set of functions (which increases the set of different > configs we need to test with). If there's a performance problem > with that we should get it fixed in gthread:-) A user-space longjmp will always be slower than a mutex+condvar+context switch. We're talking _orders of magnitude_ slower. At this point it's better to write assembly, since we already support only a dozen TCG targets. I played with an alternative implementation using a 2-barrier instead of mutex+condvar, but it didn't give any speedup and was still much slower than gthread. Paolo