[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: |
Jamie Lokier |
Subject: |
Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu |
Date: |
Mon, 31 Aug 2009 23:25:42 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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
- [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, (continued)
- [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Glauber Costa, 2009/08/27
- [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Anthony Liguori, 2009/08/27
- [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Glauber Costa, 2009/08/27
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Gleb Natapov, 2009/08/28
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Jamie Lokier, 2009/08/28
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Glauber Costa, 2009/08/31
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Jamie Lokier, 2009/08/31
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Glauber Costa, 2009/08/31
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Jan Kiszka, 2009/08/31
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu,
Jamie Lokier <=
- Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Glauber Costa, 2009/08/31
- [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Paolo Bonzini, 2009/08/31