From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mi5su-0003nk-Ch for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:21:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mi5sq-0003nE-UX for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:21:20 -0400 Received: from [199.232.76.173] (port=46580 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mi5sq-0003nB-SJ for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:21:16 -0400 Received: from goliath.siemens.de ([192.35.17.28]:15164) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mi5so-00018p-Io for qemu-devel@nongnu.org; Mon, 31 Aug 2009 08:21:15 -0400 Message-ID: <4A9BC034.2090101@siemens.com> Date: Mon, 31 Aug 2009 14:21:08 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu References: <1247781328-17249-1-git-send-email-glommer@redhat.com> <4A96BF30.7090200@siemens.com> <20090828011856.GE5746@mothafucka.localdomain> <4A973530.4040002@us.ibm.com> <20090829012227.GH8036@shareable.org> <20090831113518.GD30340@mothafucka.localdomain> <20090831120452.GG7129@shareable.org> <20090831121428.GE30340@mothafucka.localdomain> In-Reply-To: <20090831121428.GE30340@mothafucka.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Anthony Liguori , "qemu-devel@nongnu.org" , "avi@redhat.com" Glauber Costa wrote: > On Mon, Aug 31, 2009 at 01:04:52PM +0100, Jamie Lokier wrote: >> Glauber Costa wrote: >>> On Sat, Aug 29, 2009 at 02:22:27AM +0100, Jamie Lokier wrote: >>>> Anthony Liguori wrote: >>>>> Glauber Costa wrote: >>>>> Since we already keep the tid in the vcpu structure, it seems to make >>>>> more sense to ask "am I this vcpu thread" by doing gettid() == env->tid >>>>> than by maintaining a new global tls variable. >>>> Note that a tls variable will be much faster than gettid(). Don't >>>> know if you're talking about a hot path. >>> just to be sure, TLS is not supported on all our linux target hosts, right? >>> >>> We can probably wrap it into a function that uses gettid on linux (or whatever >>> in other platforms), and uses a TLS variable where available. (and if needed). >>> >>> I can agree with anthony that although TLS is in fact faster, we might not need it. >>> I doubt that anything that communicates using signals will be the hot path for anything. >> I was going to say just use pthread_self()! It's fast like TLS on all >> hosts, and more portable then gettid(). >> >> But then you mentioned signals. I'm not sure if the code in question >> is inside signal handlers. > Signals are just used to wake up the other cpu. I think it is pretty valid > to rule out usage insigne signal handlers (mention in comments, etc). > > I'll propose that switch on qemu-kvm, which already uses tls variables, and see > what the response is. > To my experience, TLS can cause a lot of problems, but only when used close to inline assembly (gcc is still horribly broken then, clobbering or "optimizing" register content, specifically on ARM). I do not expect problems for our standard use cases. But in case someone still does not feel well about it: pthread_get/set_specific can serve as a "safer" alternative that is also syscall-free (where possible). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux