From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9849FC5478C for ; Mon, 4 Mar 2024 18:15:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NJZyPRsebTIFzYuW4N1TqptOiGYR1Jph1tBEWwJ2UQA=; b=QlGMwtAlGpq6yu igDrSCuwSi4NjSCMjerJyCicx3lQftn5kSb/t2C4aPjsRBvev0kwxW1aZyooulEzQghqOsP1zI6qn 3u1Q8O8Z63Uxp65dCGjHVlRqrj+Zeqw/+q8arbQ9mv6IMf7C4GvbJYp0UwfDMTIxoCg43LLGaGSs5 ZHQj1v4CAT325sIAPl3TAuwvd6F7YRrgnEOak3TnQWXULp4taG3E7yD5oieost3qfe9ISO3IreKEQ Ne98m5BIJEMc2QkjGv9V+1FJCi+AYhENvyvoNLyWcdGHmyr3mjLGCMR5VcW+qc2nlP1M7X35cj5hI jN4q1Em5Zf3Qoi5EzZRQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhCqg-0000000A9J7-15iW; Mon, 04 Mar 2024 18:15:38 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rhCqY-0000000A9Hf-2kEV for linux-arm-kernel@lists.infradead.org; Mon, 04 Mar 2024 18:15:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F0EC460F29; Mon, 4 Mar 2024 18:15:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22725C433C7; Mon, 4 Mar 2024 18:15:27 +0000 (UTC) Date: Mon, 4 Mar 2024 18:15:25 +0000 From: Catalin Marinas To: Christoph Lameter Cc: linux-arm-kernel@lists.infradead.org, "tokamoto@jp.fujitsu.com" , "qi.fuli@fujitsu.com" , Takao Indoh , Will Deacon , Jon Masters Subject: Re: [RFC 3/8] ARM64: Base TLB functions Message-ID: References: <20231207035703.158053467@gentwo.org> <20231207035712.933420164@gentwo.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231207035712.933420164@gentwo.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240304_101531_769535_18D9F34C X-CRM114-Status: GOOD ( 17.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Christoph, I don't think any of these patches made it to the list for some reason, only the cover letter. I'll add some general comments below in case you plan to repost. On Wed, Dec 06, 2023 at 07:57:06PM -0800, Christoph Lameter wrote: > Add a series of TLB function that allow TLB flushing in a variety of > ways depending on the mode encoded in enum tlb_state: > > TLB_BROADCOAST -> Use single TLBI propagated to all units via the mesh > TLB_LOCAL -> Use TLBI that only perform local flushes > TLB_IPI -> Use TLBIs that perform local flushes on multiple cpus > TLB_NONE -> Suppress TLBI because there are no users of the address space TLB_IPI - I really don't want this on arm64, irrespective of the performance improvement on specific hardware. IPIs need additional care to avoid deadlocking, e.g. don't do a TLBI with interrupts disabled. I'd rather not have to care about this. TLB_LOCAL and TLB_NONE - these are potentially useful _but_ they don't take the SMMU with SVA into account (another potential issue below). The mm_cpumask() does not track other non-CPU contexts but they do need the broadcast TLBI. > +static enum tlb_state tlbstat(struct cpumask *mask) > +{ > + unsigned int weight = cpumask_weight(mask); > + bool present = cpumask_test_cpu(smp_processor_id(), mask); Is this guaranteed to be called in a non-preemptible context? My biggest concern with the cpumask tracking is that the thread is migrated in the middle of a TLB flush and it would wrongly assume that only a local TLBI is needed. On arm64 we don't flush the TLBs on context switch. I don't think we can solve this without additional locking around mm_cpumask() or at least preemption disabling. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel