Re: [patch 2/4] KVM: move coalesced_mmio locking to its own device

Avi Kivity
2009-05-26T13:28:00Z

Marcelo Tosatti wrote:
>>
>> Why not use slots_lock to protect the entire iodevice list (rcu one
>> day), and an internal spinlock for coalesced mmio?
>>
>
> Don't like using slots_lock to protect the entire iodevice list, its
> reverse progress in my opinion. The PIO/MMIO device lists are data
> structures used in hot path, they are not directly related to the
> memslots, and therefore deserve a separate lock. Whenever slots_lock
> becomes an issue, you'll have to entangle the mess, so better start
> doing it now.
>

It's a reader/writer lock, so you'll never have contention.

I'm okay with a new lock though.

> Sure can switch to a internal spinlock for coalesced_mmio, but breaking
> out if spin_trylock fails. You're OK with that?
>

Why not do a normal spin_lock()? It's not like you'll wait years for
the store to complete.

--
error compiling committee.c: too many arguments to function