Messages in this thread | | | Date | Sun, 21 Jun 2009 19:12:43 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [GIT PULL] core kernel fixes |
| |
On Sat, 20 Jun 2009, Linus Torvalds wrote: > On Sat, 20 Jun 2009, Linus Torvalds wrote: > > > > On x86, the natural way to do what you want done is ONE SINGLE > > INSTRUCTION! As far as I can tell, the above crazy function is 100% > > equivalent to this: > > > > asm __inline__("lock ; addl $0,%0":"+m" (*uaddr): :"memory", "cc"); > > > > which really makes me think that using "get_user_pages_fast()" for it is > > some truly crazy crap. > > We could also take the opposite approach - knowing that this is called > only when the page doesn't exist, and just doing > > down_read(mmap_sem) > vma = find_vma(..) > ret = VM_FAULT_ERROR; > if (vma && vma->vm_start <= address) > ret = handle_mm_fault(mm, vma, address, 1); > up_read(mmap_sem); > return (ret & VM_FAULT_ERROR) ? -EFAULT : 0; > > or something like that. Again, that looks saner than using > get_user_pages() for this and then dropping the page.
Hmm. The main reason why we switched to get_user_pages_fast() in the futex code is to avoid mmap_sem contention which was observed as a real big performance problem especially with those horrible JavaVM applications.
As a fallout of this we got rid of the private find_vma / handle_mm_fault magic (as above) in the futex code which mm folks frowned upon for quite a while. Unfortunately we got it wrong :(
I agree that in the fault path we might go back to the mmap_sem version, but I want to avoid it when possible. At least we need to run some of those horrible JavaVM apps to see whether it matters or not.
OTOH, I really wonder whether we can simplify the whole logic when we keep the page reference for the atomic access to the user space address, but I still have doubts about the life time rules of all this. Also I need to find out how this would affect the fast path optimization of private futexes where we avoid the lookup in the first place.
Thanks,
tglx
| |