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

[Jan Kiszka <jan.kiszka@siemens.com>]

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).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux