Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2139811pxb; Mon, 22 Feb 2021 22:26:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHx5wDYGGP/HI/5cVxdX9B68AvBmsDjtY3+UjXYdFMmPIW28esLE2GHPNvSd1OFwZkpIbr X-Received: by 2002:a17:906:d155:: with SMTP id br21mr24316156ejb.503.1614061596527; Mon, 22 Feb 2021 22:26:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614061596; cv=none; d=google.com; s=arc-20160816; b=Tes+/f5QCb6UzzfBunGPNradBWCI1dwpEb5qZ3gxdqN5kvngrJy+1E8gdkmWpqYSgM KtXAyNwIWk5ST8qwTFvwSGyjuGYMKyb6x6v7/zceO1VB+FIuK/l38M6SdcDc5W2fN+oo lQ3LH+qrhRXpY8QkPYiXQ/xpDcMnpYTu7i1+JD/EuGa1exX8QkuO91bCDY7Rcs3/VahX G1W7eesIHPO8Wjq0X901kDwFhSZOgChppywV1bdwM9qtkh27OlcbbLuwFEVx9hO6gzPh cxGZNexdx8rK8KwrVP1QEX1PpieE0yAJImfHmjwcsODXoI8YzRoQ06BHQYVYFJxNm6hB zoPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=4U84LkL3O0w3emhxW81nFudtnyrsYVkhYnasEuKmAVQ=; b=wJ8B1k7ZYhW01leQY9GaXeJr/jCSqagHX/uxtNVQtrst+WHvo+6DYiJdD6ROYWKNo+ SACRsRPm/2rixCxpeUsfCXH1Ru7g4zdx5w/pb/Pet2w3hG5XcCdnKygpolfFxQgkUGLD JmgOcmACzWIWK47zUh3jaeeGSsir29xcnrYSJorEd239u/9qtmFstyL2cxGwNzuoPPke EdXoLGGvmZfoz+/fRcLUlD3KAfVkiZKXVLePrlHiqXCoMwK+UaD1yesF1w3mNUcfNz+g UEQU9IRqSQbT1rZUPRl21RcHC7x+R//iorpzhjUrMadp8tEKZpsfkbSB3N+gIRGFiz0P kfuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e3si13939527ejm.395.2021.02.22.22.25.57; Mon, 22 Feb 2021 22:26:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230490AbhBWGKj (ORCPT + 99 others); Tue, 23 Feb 2021 01:10:39 -0500 Received: from foss.arm.com ([217.140.110.172]:59710 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229949AbhBWGKi (ORCPT ); Tue, 23 Feb 2021 01:10:38 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 409E7ED1; Mon, 22 Feb 2021 22:09:52 -0800 (PST) Received: from [192.168.0.130] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 368173F73D; Mon, 22 Feb 2021 22:09:47 -0800 (PST) Subject: Re: [PATCH] Documentation/features: mark BATCHED_UNMAP_TLB_FLUSH doesn't apply to ARM64 To: Barry Song , corbet@lwn.net, linux-doc@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxarm@openeuler.org, Mel Gorman , Andy Lutomirski , Catalin Marinas , Will Deacon References: <20210223003230.11976-1-song.bao.hua@hisilicon.com> From: Anshuman Khandual Message-ID: <09dd1026-9e3f-b9be-b5a5-82771642348d@arm.com> Date: Tue, 23 Feb 2021 11:40:09 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210223003230.11976-1-song.bao.hua@hisilicon.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/23/21 6:02 AM, Barry Song wrote: > BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by > sending one IPI to TLB flush all entries after unmapping pages rather > than sending an IPI to flush each individual entry. > On arm64, tlb shootdown is done by hardware. Flush instructions are > innershareable. The local flushes are limited to the boot (1 per CPU) > and when a task is getting a new ASID. Is there any previous discussion around this ? > So marking this feature as "TODO" is not proper. ".." isn't good as > well. So this patch adds a "N/A" for this kind of features which are > not needed on some architectures. > > Cc: Mel Gorman > Cc: Andy Lutomirski > Cc: Catalin Marinas > Cc: Will Deacon > Signed-off-by: Barry Song > --- > Documentation/features/arch-support.txt | 1 + > Documentation/features/vm/TLB/arch-support.txt | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/features/arch-support.txt b/Documentation/features/arch-support.txt > index d22a1095e661..118ae031840b 100644 > --- a/Documentation/features/arch-support.txt > +++ b/Documentation/features/arch-support.txt > @@ -8,4 +8,5 @@ The meaning of entries in the tables is: > | ok | # feature supported by the architecture > |TODO| # feature not yet supported by the architecture > | .. | # feature cannot be supported by the hardware > + | N/A| # feature doesn't apply to the architecture NA might be better here. s/doesn't apply/not applicable/ in order to match NA. Still wondering if NA is really needed when there is already ".." ? Regardless either way should be fine. > > diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt > index 30f75a79ce01..0d070f9f98d8 100644 > --- a/Documentation/features/vm/TLB/arch-support.txt > +++ b/Documentation/features/vm/TLB/arch-support.txt > @@ -9,7 +9,7 @@ > | alpha: | TODO | > | arc: | TODO | > | arm: | TODO | > - | arm64: | TODO | > + | arm64: | N/A | > | c6x: | .. | > | csky: | TODO | > | h8300: | .. | >