[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Wait Queues
On 08/11/2012 03:22, "Andres Lagar-Cavilla" <andreslc@xxxxxxxxxxxxxx> wrote: >> I'd like to propose an approach that ensures that as long some properties are >> met, arbitrary wait queue sleep is allowed. Here are the properties: >> 1. Third parties servicing a wait queue sleep are indeed third parties. In >> other words, dom0 does not do paging. >> 2. Vcpus of a wait queue servicing domain may never go to sleep on a wait >> queue during a foreign map. >> 3. A guest vcpu may go to sleep on a wait queue holding any kinds of locks as >> long as it does not hold the p2m lock. > > N.B: I understand (now) this may cause any other vcpu contending on a lock > held by the wait queue sleeper to not yield to the scheduler and pin its > physical cpu. > > What I am struggling with is coming up with a solution that doesn't turn > hypervisor mm hacking into a locking minefield. > > Linux fixes this with many kinds of sleeping synchronization primitives. A > task can, for example, hold the mmap semaphore and sleep on a wait queue. Is > this the only way out of this mess? Not if wait queues force the vcpu to wake > up on the same phys cpu it was using at the time of sleeping?. Well, the forcing to wake up on same phys cpu it slept on is going to be fixed. But it's not clear to me how that current restriction makes the problem harder? What if you were running on a single-phys-cpu system? As you have realised, the fact that all locks in Xen are spinlocks makes the potential for deadlock very obvious. Someone else gets scheduled and takes out the phys cpu by spinning on a lock that someone else is holding while they are descheduled. Linux-style sleeping mutexes might help. We could add those. They don't help as readily as in the Linux case however! In some ways they push the deadlock up one level of abstraction, to the virt cpu (vcpu). Consider single-vcpu dom0 running a pager -- even if you are careful that the pager itself does not acquire any locks that one of its clients may hold-while-sleeping, if *anything* running in dom0 can acquire such a lock, you have an obvious deadlock, as that will take out the dom0 vcpu and leave it blocked forever waiting for a lock that is held while its holder waits for service from the dom0 vcpu.... I don't think there is an easy solution here! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |