DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F2B3463764
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jork Loeser <Jork.Loeser@microsoft.com>,
        KY Srinivasan <kys@microsoft.com>, Simon Xiao <sixiao@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        "luto\@kernel.org" <luto@kernel.org>, "hpa\@zytor.com" <hpa@zytor.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "rostedt\@goodmis.org" <rostedt@goodmis.org>,
        "andy.shevchenko\@gmail.com" <andy.shevchenko@gmail.com>,
        "tglx\@linutronix.de" <tglx@linutronix.de>,
        "mingo\@kernel.org" <mingo@kernel.org>,
        "linux-tip-commits\@vger.kernel.org" 
        <linux-tip-commits@vger.kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Juergen Gross <jgross@suse.com>
Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush
References: <20170802160921.21791-8-vkuznets@redhat.com>
        <tip-2ffd9e33ce4af4e8cfa3e17bf493defe8474e2eb@git.kernel.org>
        <20170810185646.GI6524@worktop.programming.kicks-ass.net>
        <DM5PR21MB0476915D204F850F7F7C1475A0880@DM5PR21MB0476.namprd21.prod.outlook.com>
        <CY4PR21MB06313B9D59F8846CDDE443F0F1880@CY4PR21MB0631.namprd21.prod.outlook.com>
        <20170810192742.GJ6524@worktop.programming.kicks-ass.net>
        <CY4PR21MB0631989FA0C9135AAD2DD1F8F1890@CY4PR21MB0631.namprd21.prod.outlook.com>
        <20170811090336.lfznz6qzrbhiqwvi@hirez.programming.kicks-ass.net>
        <CA+55aFyXo3CtOCEKn54uA0=21O-KV0zLGvueVujCDSU--kJ7_A@mail.gmail.com>
        <20170811162605.tr4tig4av3q4fll6@hirez.programming.kicks-ass.net>
        <87fucup9ou.fsf@vitty.brq.redhat.com>
        <87shgrmpko.fsf@vitty.brq.redhat.com>
        <817e2efa-6154-a1c6-8ec7-de04324d6df8@oracle.com>
Date: Thu, 17 Aug 2017 09:58:23 +0200
In-Reply-To: <817e2efa-6154-a1c6-8ec7-de04324d6df8@oracle.com> (Boris
        Ostrovsky's message of "Wed, 16 Aug 2017 17:41:12 -0400")
Message-ID: <874lt639sw.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2066
Lines: 67

Boris Ostrovsky <boris.ostrovsky@oracle.com> writes:

> On 08/16/2017 12:42 PM, Vitaly Kuznetsov wrote:
>> Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>>
>>> In case we decide to go HAVE_RCU_TABLE_FREE for all PARAVIRT-enabled
>>> kernels (as it seems to be the easiest/fastest way to fix Xen PV) - what
>>> do you think about the required testing? Any suggestion for a
>>> specifically crafted micro benchmark in addition to standard
>>> ebizzy/kernbench/...?
>> In the meantime I tested HAVE_RCU_TABLE_FREE with kernbench (enablement
>> patch I used is attached; I know that it breaks other architectures) on
>> bare metal with PARAVIRT enabled in config. The results are:
>>
>>...
>>
>> As you can see, there's no notable difference. I'll think of a
>> microbenchmark though.
>
> FWIW, I was about to send a very similar patch (but with only Xen-PV
> enabling RCU-based free by default) and saw similar results with
> kernbench, both Xen PV and baremetal.
>

Thanks for the confirmation,

I'd go with enabling it for PARAVIRT as we will need it for Hyper-V too.

<snip>

>>  
>>  #if CONFIG_PGTABLE_LEVELS > 4
>>  void ___p4d_free_tlb(struct mmu_gather *tlb, p4d_t *p4d)
>>  {
>>  	paravirt_release_p4d(__pa(p4d) >> PAGE_SHIFT);
>> +#ifdef CONFIG_HAVE_RCU_TABLE_FREE
>> +	tlb_remove_table(tlb, virt_to_page(p4d));
>> +#else
>>  	tlb_remove_page(tlb, virt_to_page(p4d));
>> +#endif
>
> This can probably be factored out.
>
>>  }
>>  #endif	/* CONFIG_PGTABLE_LEVELS > 4 */
>>  #endif	/* CONFIG_PGTABLE_LEVELS > 3 */
>> diff --git a/mm/memory.c b/mm/memory.c
>> index e158f7ac6730..18d6671b6ae2 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -329,6 +329,11 @@ bool __tlb_remove_page_size(struct mmu_gather *tlb, struct page *page, int page_
>>   * See the comment near struct mmu_table_batch.
>>   */
>>  
>> +static void __tlb_remove_table(void *table)
>> +{
>> +	free_page_and_swap_cache(table);
>> +}
>> +
>
> This needs to be a per-arch routine (e.g. see arch/arm64/include/asm/tlb.h).
>

Yea, this was a quick-and-dirty x86-only patch.

-- 
  Vitaly