[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 21/22] tcg: enable per-thread TCG for softmmu
From: |
Emilio G. Cota |
Subject: |
Re: [Qemu-devel] [PATCH 21/22] tcg: enable per-thread TCG for softmmu |
Date: |
Mon, 10 Jul 2017 17:14:46 -0400 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Mon, Jul 10, 2017 at 14:05:01 +0200, Paolo Bonzini wrote:
> On 09/07/2017 09:50, Emilio G. Cota wrote:
> > User-mode is kept out of this: contention due to concurrent translation
> > is more commonly found in full-system mode.
>
> Out of curiosity, is it harder or you just didn't try? It would be nice
> if the commit message mentioned the problems (if any) in addition to the
> reason why you didn't do it.
>
> Having similar policies for user and softmmu emulation is much more
> maintainable (for an earlier example, see the unification of user mode
> emulation's start/end_exclusive logic with softmmu's "safe work").
I agree that it would be nice to have the same mechanism for all.
The main hurdle I see is how to allow for concurrent code generation while
minimizing flushes of the single, fixed-size[*] code_gen_buffer.
In user-mode this is tricky because there is no way to bound the number
of threads that might be spawned by the guest code (I don't think reading
/proc/sys/kernel/threads-max is a viable solution here).
Switching to a "__thread *tcg_ctx_ptr" model will help minimize
user-mode/softmmu differences though. The only remaining difference would be
that user-mode would need tb_lock() around tb_gen_code, whereas softmmu
wouldn't, but everything else would be the same.
E.
[*] Note that in user-mode we use code_gen_buffer defined at compile-time
as a static buffer[].
[Qemu-devel] [PATCH 17/22] tcg: distribute profiling counters across TCGContext's, Emilio G. Cota, 2017/07/09
Re: [Qemu-devel] [PATCH 00/22] tcg: per-thread TCG, Emilio G. Cota, 2017/07/09
Re: [Qemu-devel] [PATCH 00/22] tcg: per-thread TCG, Alex Bennée, 2017/07/10