[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: |
Thu, 15 Jan 2015 14:34:18 +0100 |
I think we call that flag “please dont reallocate this TB until at least after
a CPU has exited and we do a global flush”… So if we sync and get all cpu’s to
exit on a global flush, this flag is only there as a figment of our imagination…
e.g. we’re safe without it?
Wish I could say the same of global_mutex :-(
Cheers
Mark.
> On 15 Jan 2015, at 14:30, Frederic Konrad <address@hidden> wrote:
>
> On 15/01/2015 12:14, Alexander Graf wrote:
>>
>> On 15.01.15 12:12, Paolo Bonzini wrote:
>>> [now with correct listserver address]
>>>
>>> On 15/01/2015 11:25, Frederic Konrad wrote:
>>>> Hi everybody,
>>>>
>>>> In case of multithread TCG what is the best way to handle
>>>> qemu_global_mutex?
>>>> We though to have one mutex per vcpu and then synchronize vcpu threads when
>>>> they exit (eg: in tcg_exec_all).
>>>>
>>>> Is that making sense?
>>> The basic ideas from Jan's patch in
>>> http://article.gmane.org/gmane.comp.emulators.qemu/118807 still apply.
>>>
>>> RAM block reordering doesn't exist anymore, having been replaced with
>>> mru_block.
>>>
>>> The patch reacquired the lock when entering MMIO or PIO emulation.
>>> That's enough while there is only one VCPU thread.
>>>
>>> Once you have >1 VCPU thread you'll need the RCU work that I am slowly
>>> polishing and sending out. That's because one device can change the
>>> memory map, and that will cause a tlb_flush for all CPUs in tcg_commit,
>>> and that's not thread-safe.
>> You'll have a similar problem for tb_flush() if you use a single tb
>> cache. Just introduce a big hammer function for now that IPIs all the
>> other threads, waits until they halted, do the atomic instruction (like
>> change the memory map or flush the tb cache), then let them continue.
>>
>> We can later one-by-one get rid of all callers of this.
>>
>>
>> Alex
> Maybe we can put a flag in the tb to say it's being executed so tb_alloc
> won't try to
> realloc it?
>
> Maybe it's a bad idea and will be actually slower than exiting and waiting
> all the other
> cpu.
>
> Fred
+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., 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, 2015/01/16