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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
