[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:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
- [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, 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 <=
- 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
- [Qemu-devel] Re: [PATCH v3] introduce on_vcpu, Paolo Bonzini, 2009/08/31