[Top][All Lists]

[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:14:28 -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().
> 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.

reply via email to

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