Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 01 Apr 2010 19:02:51 +0300 | From | Avi Kivity <> | Subject | Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all_locks() |
| |
On 04/01/2010 06:54 PM, Andrea Arcangeli wrote: > >>> The only single reason I'd go for mutexes would be to accommodate >>> XPMEM requirements once and for all, no other reason. >>> >>> >> There is also a minor benefit for kvm. Reduced latency over large mmu >> operations; code simplification (we now have some >> copy_from_user_inatomic() that could be simplified). >> > Where exactly is KVM taking these locks?
Not these locks, but if we go all the way and make mmu notifiers sleepable, we can convert mmu_lock to a mutex.
> KVM should only call into > GUP, and GUP itself won't iterate over rmaps either. GUP just walks > the host pagetables and trigger page faults if the pages aren't > mapped.
We'll probably deadlock then, gup -> change_pte notifier -> mmu_lock. But we can probably work around it.
> I don't see how you're going to remove > copy_from_user_inatomic() given we don't have vmas and other metadata > to take those locks. Maybe we can stop calling GUP but even if we take > the anon_vma mutex/semaphore I think it won't still prevent munmap to > drop the anon pages from under us (even if it'd stop the VM to unmap > them through rmap). To freeze the mapping one would need to take > mmap_sem in write mode in addition to the anon_vma mutex/sem which is > unlikely a win compared to just gup+copy_from_user_inatomic. So I > don't see immediate benefits for KVM but maybe I'm missing something > of course! >
I meant replace c_f_u_inatomic() by c_f_u() (that's why the benefit is minor - we only simplify the failure path). Sorry for being unclear.
-- error compiling committee.c: too many arguments to function
| ![\](/images/icornerr.gif) |