From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiFJw-0006mW-Ad for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:25:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiFJq-0006l5-T1 for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:25:51 -0400 Received: from [199.232.76.173] (port=45659 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiFJq-0006l2-Mq for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:25:46 -0400 Received: from mail2.shareable.org ([80.68.89.115]:60034) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MiFJp-0005nk-Kg for qemu-devel@nongnu.org; Mon, 31 Aug 2009 18:25:46 -0400 Date: Mon, 31 Aug 2009 23:25:42 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu Message-ID: <20090831222542.GC24318@shareable.org> 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> <4A9BC034.2090101@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9BC034.2090101@siemens.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Glauber Costa , "avi@redhat.com" , Anthony Liguori , "qemu-devel@nongnu.org" Jan Kiszka wrote: > 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). Just so y'all know, pthread_get/set_specific are also unsafe inside signal handlers for the same reason as pthread_self is unsafe. -- Jamie