MIME-Version: 1.0
In-Reply-To: <20170829204901.GC13559@redhat.com>
References: <0dcca3a4-8ecd-0d05-489c-7f6d1ddb49a6@gmx.de> <79BC5306-4ED4-41E4-B2C1-12197D9D1709@gmail.com>
 <aab6d214-9393-f9d3-b19d-37fbb8971f31@gmx.de> <s5hh8wq8ruy.wl-tiwai@suse.de>
 <20170829125923.g3tp22bzsrcuruks@angband.pl> <20170829140924.GB21615@redhat.com>
 <20170829183405.GB7546@redhat.com> <CA+55aFxrzKt2NpgERtg+QwxFPHZ1vMFNxyWEtrQR2-Hj3-xxLg@mail.gmail.com>
 <20170829191351.GD7546@redhat.com> <CA+55aFwq3M+asJz+1G1iU3pWLqWKnRD-7ufASERYA5vPZfVeLA@mail.gmail.com>
 <20170829204901.GC13559@redhat.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 29 Aug 2017 13:59:35 -0700
Message-ID: <CA+55aFyPu8ZG+iFsxQz4_W8PoSkZYUmq2uJCY2+n_SetvbFTtw@mail.gmail.com>
Subject: Re: kvm splat in mmu_spte_clear_track_bits
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jerome Glisse <jglisse@redhat.com>,
        Adam Borowski <kilobyte@angband.pl>, Takashi Iwai <tiwai@suse.de>,
        Bernhard Held <berny156@gmx.de>, Nadav Amit <nadav.amit@gmail.com>,
        Paolo Bonzini <pbonzini@redhat.com>, Wanpeng Li <kernellwp@gmail.com>,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Joerg Roedel <jroedel@suse.de>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>, kvm <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Michal Hocko <mhocko@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 946
Lines: 21

On Tue, Aug 29, 2017 at 1:49 PM, Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> mmu_notifier_invalidate_page has the advantage that it takes the
> secondary MMU KVM srcu and spinlock a single time.

Note that that isn't actually all that much of an advantage - it turns
out that a lot of users have "range_start", but not "range_end".

So in a lot of cases, the "range_start/end()" seems to be exactly as
expensive as just the single "page()" call, simply because the code
didn't really need the whole range, it only wanted to make sure it was
invalidating its data before the range got modified.

KVM ends up doing a partial case of that optimization too: it doesn't
do the srcu lock in the end case, for example.  It does want to keep
the sequence numbers for the end case, but that's fairly cheap.

So I'd much rather have the simpler rules than have duplicated
interfaces for some very dubious performance advantage.

               Linus