Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Vitaly Kuznetsov <vkuznets@redhat.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Andy Lutomirski <luto@amacapital.net>,
        Rik van Riel <riel@surriel.com>,
        Andy Lutomirski <luto@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Mike Galbraith <efault@gmx.de>,
        kernel-team <kernel-team@fb.com>, Ingo Molnar <mingo@kernel.org>,
        Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH 4/7] x86,tlb: make lazy TLB mode lazier
References: <20180716190337.26133-1-riel@surriel.com>
        <20180716190337.26133-5-riel@surriel.com>
        <CALCETrUMntRe_LYX5wj9YD4xZ+84QExK+ZNb3yxEBDEKa7nePQ@mail.gmail.com>
        <B6566AA4-2E8A-43BD-A224-0F6D4747B8FB@surriel.com>
        <F93A3335-4830-4E36-9179-D0FA5D640C8A@amacapital.net>
        <B976CC13-D014-433A-83DE-F8DF9AB4F421@surriel.com>
        <CALCETrWDiMhgiR3f8n0jdWcW31EDJ+Waq0wh5sMDutfigANGnA@mail.gmail.com>
        <87muumtjwd.fsf@vitty.brq.redhat.com>
        <20180720094906.GP2494@hirez.programming.kicks-ass.net>
Date:   Fri, 20 Jul 2018 12:18:28 +0200
In-Reply-To: <20180720094906.GP2494@hirez.programming.kicks-ass.net> (Peter
        Zijlstra's message of "Fri, 20 Jul 2018 11:49:06 +0200")
Message-ID: <87fu0etdl7.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Peter Zijlstra <peterz@infradead.org> writes:

> On Fri, Jul 20, 2018 at 10:02:10AM +0200, Vitaly Kuznetsov wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>> 
>> > [I added PeterZ and Vitaly -- can you see any way in which this would
>> > break something obscure?  I don't.]
>> 
>> Thanks for CCing me,
>> 
>> I don't see how this can break things either. At first glance, however,
>> I'm afraid we can add performance penalty to virtualized guests which
>> don't use native_flush_tlb_others() (Hyper-V, KVM): we will be reloading
>> CR3 without a need as we don't look at lazy mode in PV tlb flush
>> functions.
>> 
>> We can either check to switch_mm_irqs_off() that
>> native_flush_tlb_others() is in use or teach PV tlb flush functions to
>> look at lazy mode too.
>
> As Rik noted elsewhere in the thread, kvm_flush_tlb_others() ends up
> calling native_tlb_flush_others() for all running vcpu threads.

Ah, right!

>
> The Hyper-V thing is magical, we can't really do anything about it
> there. Let them worry about it.

Well, we kinda know how this magic works: we just ask the hypervisor to
flush TLB for us (if the particular vCPU is running) :-) Anyway, nothing
stops us from duplicating the logic regarding lazy mode from
native_flush_tlb_others() to hyperv_flush_tlb_others(): if TLB state is
lazy omit TLB flush.

-- 
  Vitaly