On Mon, May 09, 2016 at 13:21:50 +0200, Paolo Bonzini wrote:
> On 30/04/2016 05:40, Emilio G. Cota wrote:
> >> The tb_flush
> >> > is a fairly rare occurrence its not like its on the critical performance
> >> > path (although of course pathological cases are possible).
> > This is what I thought fr
Paolo Bonzini writes:
> On 09/05/2016 13:50, Alex Bennée wrote:
>> > Which locks? tb_lock during tb_find_fast? The problem with that was
>> > that it slowed down everything a lot, wasn't it?
>>
>> Very much so, in the new tree (coming soon) with QHT I was able to
>> remove the locks from the w
On 09/05/2016 13:50, Alex Bennée wrote:
> > Which locks? tb_lock during tb_find_fast? The problem with that was
> > that it slowed down everything a lot, wasn't it?
>
> Very much so, in the new tree (coming soon) with QHT I was able to
> remove the locks from the whole hot-path which means the
Paolo Bonzini writes:
> On 30/04/2016 05:40, Emilio G. Cota wrote:
>>> The tb_flush
>>> > is a fairly rare occurrence its not like its on the critical performance
>>> > path (although of course pathological cases are possible).
>> This is what I thought from the beginning, but wanted to give thi
On 30/04/2016 05:40, Emilio G. Cota wrote:
>> The tb_flush
>> > is a fairly rare occurrence its not like its on the critical performance
>> > path (although of course pathological cases are possible).
> This is what I thought from the beginning, but wanted to give this
> alternative a go anyway t
On Tue, Apr 26, 2016 at 07:32:39 +0100, Alex Bennée wrote:
> Emilio G. Cota writes:
> > With two code_gen "halves", if two tb_flush calls are done in the same
> > RCU read critical section, we're screwed. I added a cpu_exit at the end
> > of tb_flush to try to mitigate this, but I haven't audited
On 04/25/2016 11:35 PM, Alex Bennée wrote:
>
> Richard Henderson writes:
>
>> On 04/25/2016 04:46 PM, Emilio G. Cota wrote:
>>> +/*
>>> + * write the prologue into buf2. This is safe because we'll later call
>>> + * tcg_prologue_init on buf1, from which we'll start execution.
>>> +
Richard Henderson writes:
> On 04/25/2016 04:46 PM, Emilio G. Cota wrote:
>> +/*
>> + * write the prologue into buf2. This is safe because we'll later call
>> + * tcg_prologue_init on buf1, from which we'll start execution.
>> + */
>> +tcg_ctx.code_gen_buffer = code_gen_buf2;
Emilio G. Cota writes:
> Context:
> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg04658.html
> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg06942.html
>
> This seems to half-work[*] although I'm uneasy about the while idea.
> I see two major hurdles:
>
> * If the TB si
On 04/25/2016 04:46 PM, Emilio G. Cota wrote:
+/*
+ * write the prologue into buf2. This is safe because we'll later call
+ * tcg_prologue_init on buf1, from which we'll start execution.
+ */
+tcg_ctx.code_gen_buffer = code_gen_buf2;
+tcg_prologue_init(&tcg_ctx);
+
Ah, n
Context:
https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg04658.html
https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg06942.html
This seems to half-work[*] although I'm uneasy about the while idea.
I see two major hurdles:
* If the TB size is too small, this breaks badly, beca
11 matches
Mail list logo
