Am 29.11.2014 um 15:27 schrieb Paolo Bonzini:
>
> On 28/11/2014 21:52, Peter Lieven wrote:
>> master:
>> Run operation 4000 iterations 13.612604 s, 2938K operations/s, 340ns per
>> coroutine
>>
>> this series up to patch 6:
>> Run operation 4000 iterations 10.428382 s, 3835K operations/s,
On 28/11/2014 21:52, Peter Lieven wrote:
>> > +alloc_pool_size += atomic_xchg(&release_pool_size, 0);
> I had alloc_pool_size = in my original Patch.
> It shouldn't make a difference, since alloc_pool_size should be 0
> when we reach this code piece. But if for some reason release
On 28/11/2014 21:52, Peter Lieven wrote:
>
> master:
> Run operation 4000 iterations 13.612604 s, 2938K operations/s, 340ns per
> coroutine
>
> this series up to patch 6:
> Run operation 4000 iterations 10.428382 s, 3835K operations/s, 260ns per
> coroutine
>
> this series up to patc
Am 28.11.2014 um 15:12 schrieb Paolo Bonzini:
> From: Peter Lieven
>
> Placing coroutines on the global pool should be preferrable, because it
> can help all threads. But if the global pool is full, we can still
> try to save some allocations by stashing completed coroutines on the
> local pool.
From: Peter Lieven
Placing coroutines on the global pool should be preferrable, because it
can help all threads. But if the global pool is full, we can still
try to save some allocations by stashing completed coroutines on the
local pool. This is quite cheap too, because it does not require
ato
