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;
Subject: Re: [PATCH] x86/mm/tlb: Do partial TLB flush when possible
To:     Andy Lutomirski <luto@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>, srinivas.eeda@oracle.com,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        X86 ML <x86@kernel.org>
References: <1559116604-23105-1-git-send-email-zhenzhong.duan@oracle.com>
 <CALCETrU96Pjw5AEy_Aju_hMkv=QdE3YVfx5aY24B8WwDqM1A9Q@mail.gmail.com>
From:   Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
Message-ID: <66defe09-51f1-3def-6e5a-7a9c07430f65@oracle.com>
Date:   Fri, 31 May 2019 10:51:17 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CALCETrU96Pjw5AEy_Aju_hMkv=QdE3YVfx5aY24B8WwDqM1A9Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2019/5/30 22:15, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 12:56 AM Zhenzhong Duan
> <zhenzhong.duan@oracle.com> wrote:
>> This is a small optimization to stale TLB flush, if there is one new TLB
>> flush, let it choose to do partial or full flush. or else, the stale
>> flush take over and do full flush.
> I think this is invalid because:
>
>> +       if (unlikely(f->new_tlb_gen <= local_tlb_gen &&
>> +           local_tlb_gen + 1 == mm_tlb_gen)) {
>> +               /*
>> +                * For stale TLB flush request, if there will be one new TLB
>> +                * flush coming, we leave the work to the new IPI as it knows
>> +                * partial or full TLB flush to take, or else we do the full
>> +                * flush.
>> +                */
>> +               trace_tlb_flush(reason, 0);
>> +               return;
> We do indeed know that the TLB will get flushed eventually, but we're
> actually providing a stronger guarantee that the TLB will be
> adequately flushed by the time we return.  Otherwise, after
> flush_tlb_mm_range(), there will be a window in which the TLB isn't
> flushed yet.

You are right. I didn't notice this point, sorry for the noise.

Zhenzhong