Am 18.09.2012 16:44, schrieb Paolo Bonzini:
> Il 18/09/2012 13:40, Kevin Wolf ha scritto:
>> +qemu_co_mutex_unlock(&s->lock);
>> +qemu_co_rwlock_wrlock(&m->l2_writeback_lock);
>
> Can anybody else take the lock as reader again at this point? If not, I
> wonder if this is more clear if you
Il 18/09/2012 17:05, Paolo Bonzini ha scritto:
>> >>> >> +qemu_co_mutex_unlock(&s->lock);
>> >>> >> +qemu_co_rwlock_wrlock(&m->l2_writeback_lock);
>> >
>> > Can anybody else take the lock as reader again at this point? If
>> > not, I
>> > wonder if this is mor
Il 18/09/2012 17:02, Kevin Wolf ha scritto:
>>> >> +qemu_co_mutex_unlock(&s->lock);
>>> >> +qemu_co_rwlock_wrlock(&m->l2_writeback_lock);
>> >
>> > Can anybody else take the lock as reader again at this point? If not, I
>> > wonder if this is more clear if you write it as a CoQueue.
> Thi
Il 18/09/2012 13:40, Kevin Wolf ha scritto:
> +qemu_co_mutex_unlock(&s->lock);
> +qemu_co_rwlock_wrlock(&m->l2_writeback_lock);
Can anybody else take the lock as reader again at this point? If not, I
wonder if this is more clear if you write it as a CoQueue.
Paolo
> +has_wr_lock = t
This is the first part of an optimisation to improve the performance of
sequential cluster allocations.
Typically, write requests aren't aligned to cluster boundaries, so
sequential allocation means that every other request has to wait for the
COW of the previous request to complete. We can do bet
