[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: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu
Date: Mon, 31 Aug 2009 14:21:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

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


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

reply via email to

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