qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Glauber Costa
Subject: Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu
Date: Mon, 31 Aug 2009 09:57:32 -0300
User-agent: Jack Bauer

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().
> 
Just noted one thing we are missing, here.

The use we're looking at with qemu is just to ask a question like "are we 
running on
the current thread"? 

However, by looking at qemu-kvm's tree, we can see that this is not always the 
case.
We use that to answer questions like "what is the env in this thread, so I can 
inject
an interrupt?". And it kinds of smell like a possible hot path.

So although we could use pthread_getspecific() like Jan suggested, it is not as 
fast as
a TLS variable. I would then, rather, write a wrapper that does a TLS read when 
available,
and uses pthread_getspecific() otherwise.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]