[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] global_mutex and multithread.
From: |
Mark Burton |
Subject: |
Re: [Qemu-devel] global_mutex and multithread. |
Date: |
Fri, 16 Jan 2015 08:25:54 +0100 |
> On 15 Jan 2015, at 22:41, Paolo Bonzini <address@hidden> wrote:
>
>
>
> On 15/01/2015 21:53, Mark Burton wrote:
>>> Jan said he had it working at least on ARM (MusicPal).
>>
>> yeah - our problem is when we enable multi-threads - which I dont believe
>> Jan did…
>
> Multithreaded TCG, or single-threaded TCG with SMP?
He mentions SMP, - I assume thats single-threaded ….
>
>>>> One thing I wonder - why do we need to go to the extent of mutexing
>>>> in the TCG like this? Why can’t you simply put a mutex get/release on
>>>> the slow path? If the core is going to do ‘fast path’ access to the
>>>> memory, - even if that memory was IO mapped - would it matter if it
>>>> didn’t have the mutex?
>>>
>>> Because there is no guarantee that the memory map isn't changed by a
>>> core under the feet of another. The TLB (in particular the "iotlb") is
>>> only valid with reference to a particular memory map.
>>
>>>
>>> Changes to the memory map certainly happen in the slow path, but lookups
>>> are part of the fast path. Even an rwlocks is too slow for a fast path,
>>> hence the plan of going with RCU.
>>
>> Could we arrange the world such that lookups ‘succeed’ (the wheels
>> dont fall off) -ether getting the old value, or the new, but not getting
>> rubbish - and we still only take the mutex if we are going to make
>> alterations to the MM itself? (I have’t looked at the code around that…
>> so sorry if the question is ridiculous).
>
> That's the definition of RCU. :) Look at the docs in
> http://permalink.gmane.org/gmane.comp.emulators.qemu/313929 for more
> information. :)
Ahh - I see !
>
> It's still not trivial to make it 100% correct, but at the same time
> it's not too hard to prepare something decent to play with. Also, most
> of the work can be done with KVM so it's more or less independent from
> what you guys have been doing so far.
Yes - the issue is if we end up relying on it.
But - I see what you mean - these 2 things can ‘dovetail’ together
“independently” - so - Jan’s patch will be good for now, and then later we can
use RCU to make it work more generally (and more efficiently).
So - our only small problem is getting Jan’s patch to work for multi-thread :-))
Cheers
Mark.
>
> Paolo
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton
- Re: [Qemu-devel] global_mutex and multithread., (continued)
Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Paolo Bonzini, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Paolo Bonzini, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Paolo Bonzini, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread.,
Mark Burton <=
- Re: [Qemu-devel] global_mutex and multithread., Jan Kiszka, 2015/01/16
- Re: [Qemu-devel] global_mutex and multithread., Frederic Konrad, 2015/01/16
- Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/16