On Sat, Jul 26, 2008 at 03:49:15PM +0200, Andrea Arcangeli wrote: > On Sat, Jul 26, 2008 at 03:14:50PM +0200, Nick Piggin wrote: > > But I also wear a VM (as in virtual memory not virtual machine ;) hat > not just a KVM hat, so I surely wouldn't have submitted something that > I think is bad for the VM. Infact I opposed certain patches made > specifically for XPMEM that could hurt the VM a micro-bit (mostly > thinking at UP cellphones). Still I offered to support XPMEM but with > a lower priority and done right. BTW. I don't like this approach especially for XPMEM the infinite starvation will probably be a much bigger issue if tasks can go to sleep there. Perhaps priority inversion problems too. Also making the locks into sleeping locks I don't know if it is such a good approach. We have gone the other way for some reasons in the past, so they have to be addressed. > I don't happen to dislike mm_take_all_locks, as it's totally localized > and _can_never_run_ unless you load one of those kvm or gru > modules. I'd rather prefer mmu notifiers to be invisible to the > tlb-gather logic, surely it'd be orders of magnitude simpler to delete > mm_take_all_locks than to undo the changes to the tlb-gather logic. So > if something we should go with -mm first, and then evaluate if the > tlb-gather changes are better/worse. The thing about mm_take_all_locks that I don't think you quite appreciate is that it isn't totally localized. It now adds a contract to the rest of the VM to say it isn't allowed to invalidate anything while it is being run. If it literally was self contained and zero impact, of course I wouldn't care about it from the core VM perspective, but I still think it might be a bad idea for some of the GRU (and XPMEM) use cases. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
