[PATCH] KVM: x86/mmu: consider the hva in mmu_notifer retry
David Stevens
stevensd at chromium.org
Tue Jan 26 02:39:16 EST 2021
> > This has the secondary effect of greatly reducing the likelihood of extreme
>
> Out of curiosity, is this really the _secondary_ effect? I would expect this
> change to primarily benefit scenarios where the invalidation has gotten
> waylaid for whatever reason.
Yeah, this is the primary benefit. I was thinking about it as the
reduction in page fault retries is the direct effect, and that in turn
leads to a secondary effect of a reduction in the chance of extreme
latency. But I guess that's not a particularly important distinction
to make. I'll reword this.
>
> This needs a comment to explicitly state that 'count > 1' cannot be done at
> this time. My initial thought is that it would be more intuitive to check for
> 'count > 1' here, but that would potentially check the wrong wrange when count
> goes from 2->1. The comment about persistence in invalidate_range_start() is a
> good hint, but I think it's worth being explicit to avoid bad "cleanup" in the
> future.
>
> > + if (unlikely(kvm->mmu_notifier_count)) {
> > + if (kvm->mmu_notifier_range_start <= hva &&
> > + hva < kvm->mmu_notifier_range_end)
I'm not sure I understand what you're suggesting here. How exactly
would 'count > 1' be used incorrectly here? I'm fine with adding a
comment, but I'm not sure what the comment needs to clarify.
-David
More information about the linux-arm-kernel
mailing list