>>> Andrea Arcangeli <aarca...@redhat.com> 06/07/12 12:35 PM >>> >Oops, sorry I didn't imagine atomic64_read on a pmd would trip.
The problem really is that the cmpxchg8b is a write, and hence won't go through without faulting on a write protected page (which all page table pages necessarily are). >I guess if Xen can't be updated to handle an atomic64_read on a pmd in >the guest, we can add a pmd_read paravirt op? Xen could certainly be updated to treat cmpxchg8b on a PMD entry as a simple 8-byte read when compared-to and to-be-stored values are identical, but the problem would be that hypervisors in the field wouldn't necessarily get updated. >Or if we don't want to >break the paravirt interface a loop like gup_fast with irq disabled >should also work but looping + local_irq_disable()/enable() sounded >worse and more complex than a atomic64_read (gup fast already disables >irqs because it doesn't hold the mmap_sem so it's a different cost >looping there). AFIK Xen disables THP during boot, so a check on THP >being enabled and falling back in the THP=n version of >pmd_read_atomic, would also be safe, but it's not so nice to do it >with a runtime check. That would probably nevertheless be the most viable option. If performance critical(?), maybe this could be hidden with something like the alternative instruction or paravirt patching mechanisms? Jan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd114080200007800085...@nat28.tlf.novell.com
