From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 37A3D28D83F for ; Mon, 12 Jan 2026 12:00:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768219221; cv=none; b=Mk0bOqq+dbNrRvcllo6s1fFQEkmqY9HmhiBFkra4dGes39X1QTqHg6p/sJ4FRJBsHFjXlrPrhAtn1qyuTVeM9YSS5UuJeawIWXWRWQq92dnWp2/WBVQatRX4EtHR+wa2Yi1mQMcibEJ9gUz6uzRUJE41yIUIb3bO+76o0u6hb7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768219221; c=relaxed/simple; bh=NUPtuhH+HyUk0wFXf8o25W9mEZXnKUQ/YvaBganhT00=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YybczjKzQ4m/ZFMsOn/DH6wqBSfM01lWnu2JyKqSg52I6I0pTq6Fiknj/0UBbWM5MxcQnNQuxuVQLgG2fw2d56KHSXNAmsmJxZMRqgtRAcoAMzhtmMOBg/Vq76KO8SnDZez98lCu7ECLNypk5JPTJyM9z4nG4T8NTEUdFHVGOV4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 B1001497; Mon, 12 Jan 2026 04:00:12 -0800 (PST) Received: from [10.57.95.123] (unknown [10.57.95.123]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A18983F59E; Mon, 12 Jan 2026 04:00:17 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2026 12:00:16 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 11/13] arm64: mm: More flags for __flush_tlb_range() Content-Language: en-GB To: Linu Cherian Cc: Will Deacon , Ard Biesheuvel , Catalin Marinas , Mark Rutland , Linus Torvalds , Oliver Upton , Marc Zyngier , Dev Jain , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20251216144601.2106412-1-ryan.roberts@arm.com> <20251216144601.2106412-12-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/01/2026 03:21, Linu Cherian wrote: > Ryan, > > On Tue, Dec 16, 2025 at 02:45:56PM +0000, Ryan Roberts wrote: >> Refactor function variants with "_nosync", "_local" and "_nonotify" into >> a single __always_inline implementation that takes flags and rely on >> constant folding to select the parts that are actually needed at any >> given callsite, based on the provided flags. >> >> Flags all live in the tlbf_t (TLB flags) type; TLBF_NONE (0) continues >> to provide the strongest semantics (i.e. evict from walk cache, >> broadcast, synchronise and notify). Each flag reduces the strength in >> some way; TLBF_NONOTIFY, TLBF_NOSYNC and TLBF_NOBROADCAST are added to >> complement the existing TLBF_NOWALKCACHE. > > It would be nice to have some notes added on the below for better clarity > * What a walk cache is and why we bother about them ? > * Why and how should we invalidate the walk caches ? There is a large comment block already in tlbflush.h which talks about which operations affect the walk-cache and which don't. Although it never defines the walk-cache; I'll add something vague there, although I don't want to be too specific as it's a uarch thing really. Thanks, Ryan > > -- > Linu Cherian.