> > I also think we should be cautious to make this slowpath so horribly > slow. For KVM it's fine, but perhaps for GRU we'd actually want to > register quite a lot of notifiers, unregister them, and perhaps even > do per-vma registrations if we don't want to slow down other memory > management operations too much (eg. if it is otherwise just some > regular processes just doing accelerated things with GRU). I can't speak for other possible users of the mmu notifier mechanism but the GRU will only register a single notifier for a process. The notifier is registered when the GRU is opened and (currently) unregistered when the GRU is closed. If a task opens multiple GRUs (quite possible for threaded apps), all shared the same notifier. Regardless of the number of threads/opens, there will be a single notifier. At least one version of mmu notifiers did not support unregistration. The notifier was left in the chain until the task exited. This also worked for the GRU. If the gru was subsequently reopened the notifier was reused. Providing the ability to unregister is the right thing to do if the cost is not excessive. From a practical standpoint, for the GRU usage, unregistration is not a big issue either way. --- jack -- 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
