On 05/26/2011 09:05 PM, Ingo Molnar wrote:
>
> I've added some rwlocks because of what Ingo said yesterday about
> adding/removing devices after the first initialization phase.
>
> Take MMIO lock for example: Since we can now run SMP guests, we may
> have multiple MMIO exits (one from each VCPU thread). Each of those
> exits leads to searching the MMIO rbtree.
>
> We can use a mutex to lock it, but it just means that those threads
> will be blocked there instead of concurrently searching the MMIO
> tree which makes the search linear instead of parallel.
>
> It's hard to bring 'real' numbers at this stage because the only
> 'real' device we have which uses MMIO is the VESA driver, and we
> can't really simulate many VCPUs writing to it :)
I'd suggest keeping it simple first - rwlocks are nasty and will
bounce a cacheline just as much.
Well, this is the first case where tools/kvm can do better than qemu
with its global lock, so I think it's worth it.
If lookup scalability is an issue we can extend RCU to tools/kvm/.
Definitely rcu is a perfect patch for mmio dispatch.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
