Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu

[Glauber Costa <glommer@redhat.com>]

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.