[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG.
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG. |
Date: |
Tue, 11 Aug 2015 16:10:07 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
On 11/08/2015 15:59, Frederic Konrad wrote:
>> - tb_lock usage in tb_find_fast is complicated and introduces the need
>> for other complicated code such as the tb_invalidate callback. Instead,
>> the tb locking should reuse the cpu-exec.c code for user-mode emulation,
>> with additional locking in the spots identified by Fred.
>
> The reason for this is that locking around tb_find_fast just kills the
> performance.
Let's make it correct first. :)
>> - the whole signal-based qemu_cpu_kick can just go away. Just setting
>> tcg_exit_req and exit_request will kick the TCG thread. The hairy Win32
>> SuspendThread/ResumeThread goes away too. I suggest doing it now,
>> because proving it unnecessary is easier than proving it correct.
>
> Just setting tcg_exit_req and exit_request and signal the cpu->halt_cond
> I guess?
Yes.
>> - the big QEMU lock is not taken anywhere for MMIO accesses that require
>> it (i.e. basically all of them)
> Isn't that handled by prepare_mmio_access?
That's not used on the TCG path (which calls
memory_region_dispatch_read/write directly).
Paolo
- Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG., (continued)
Re: [Qemu-devel] [RFC PATCH V7 00/19] Multithread TCG., Paolo Bonzini, 2015/08/11