Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2363782pxj; Sun, 30 May 2021 23:40:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZY4kPBPk8WUeSu79d1AMAmRb1pymqCG7T7rdXQ/qspawORoK5JwdfMzq1zplNizMVLOrA X-Received: by 2002:a17:906:1444:: with SMTP id q4mr21518171ejc.459.1622443239950; Sun, 30 May 2021 23:40:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622443239; cv=none; d=google.com; s=arc-20160816; b=kuD8JMYPKndEXskPRWWRNyDHhrMGjOop1ZP+LiTC4IOm8EBM309wrIk3g4ScTjmOf4 a6Df6VzOhAf4jXLLD2T6Z4kdESQpjAOr1redJEBjVDsMy4pu2VsaK0oFFhYd1AoYWkGw hJ/VbfAWT3rtoPLXsSnZ9ZEU3T9rNYF8C+nAitKaIm88/hSFSD5xzfYz2Y6joN0yzetZ ZzoU3BZXQOejq/78Ui3IEPXArZFcr8kqgJlqZ2rwqsuXUTm7VAABSHXtCu2Ra+1GPJ+e CFItlhh+RRpm8MvVBobFAWfpKTL04nI2vBcfjzcPC+7Owljy1vVo0Vnspju1OLyBw36P OIgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=FjiVevVQeDJwIXzoYZl9qp01PcwWPwZVSgW5TN1H2Qg=; b=NRLNpqcPPO6mSjfC1i4HhdbrTJSiFn0cf1n/yvEN4sbekoGh5U387uAJW1yj5Tpxdp 7L1bYd5PNfsZWa4l4REkFW/odzKEKlx8F9Wd/4G8ntCjOgbZy8yBLwv3MHMDNK72wrd4 myZaB4m1Rrv552AjWUS8B+L+O4sebrGJ6Rcyx/wHr/r4b7DAsZJJyHZpVs7WNfyGiLI9 00w2bRNMpQORf9PHL/xfwRAagF7hwm5sYM2+mn3PZqxI0FCZxTFm64WJemuQc+4wBbbp Dg+ao2H0wOfBO4MH8d0Kv1/lM7BTTnZVf5UaCDV4BVfTkyemkK9nDkv1Rx8SOb5iSp6Z GuyQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a8si12350712ejk.310.2021.05.30.23.40.08; Sun, 30 May 2021 23:40:39 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230169AbhEaGil (ORCPT + 99 others); Mon, 31 May 2021 02:38:41 -0400 Received: from verein.lst.de ([213.95.11.211]:48269 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbhEaGik (ORCPT ); Mon, 31 May 2021 02:38:40 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 4B7F367373; Mon, 31 May 2021 08:36:58 +0200 (CEST) Date: Mon, 31 May 2021 08:36:58 +0200 From: Christoph Hellwig To: palmerdabbelt@google.com Cc: Christoph Hellwig , guoren@kernel.org, Anup Patel , Arnd Bergmann , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-sunxi@lists.linux.dev, guoren@linux.alibaba.com Subject: Re: [PATCH V4 2/2] riscv: Use use_asid_allocator flush TLB Message-ID: <20210531063658.GB1143@lst.de> References: <20210527070903.GA32653@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 29, 2021 at 04:42:37PM -0700, palmerdabbelt@google.com wrote: >> >> Also the non-ASID code switches to a global flush once flushing more >> than a single page. It might be worth documenting the tradeoff in the >> code. > > For some reason I thought we'd written this down in the commentary of teh > ISA manual as the suggested huersitic here, but I can't find it so maybe > I'm wrong. If it's actually there it would be good to point that out, > otherwise some documentation seems fine as it'll probably become a tunable > at some point anyway. The real question is why is the heuristic different for the ASID vs non-ASID case? I think that really need a comment. > LGTM. I took the first one as IMO they're really distnict issues, LMK if > you want to re-spin this one or if I should just take what's here. What distinct issue? The fact that the new code is buggy and uses rather non-optimal calling conventions?