On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > > You can avoid the page-pin and the pt lock completely by zapping the > > mappings at _start and then holding off new references until _end. > > "holding off new references until _end" = per-range mutex less scalar > and more expensive than the PT lock that has to be taken anyway.
You can of course setup a 2M granularity lock to get the same granularity as the pte lock. That would even work for the cases where you have to page pin now. > > Maybe that is true for KVM but certainly not true for the GRU. The GRU is > > designed to manage several petabytes of memory that may be mapped by a > > series of Linux instances. If a process only maps a small chunk of 4 > > Gigabytes then we already have to deal with 1 mio callbacks. > > KVM is also going to map a lot of stuff, but mapping involves mmap, > munmap/mremap/mprotect not. The size of mmap is irrelevant in both > approaches. optimizing do_exit by making the tlb-miss runtime slower > doesn't sound great to me and that's your patch does if you force GRU > to use it. The size of the mmap is relevant if you have to perform callbacks on every mapped page that involved take mmu specific locks. That seems to be the case with this approach. Optimizing do_exit by taking a single lock to zap all external references instead of 1 mio callbacks somehow leads to slowdown? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
