On Thu, May 26, 2011 at 9:11 PM, Avi Kivity <avi@xxxxxxxxxx> wrote: > 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. Userspace RCU code is here, Sasha, if you feel like tackling this: http://lttng.org/urcu :-) I'm CC'ing Paul and Mathieu as well for urcu. -- 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
