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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 20090CCA471 for ; Fri, 3 Oct 2025 09:39:04 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4cdNsK6p85z3cYP; Fri, 3 Oct 2025 19:39:01 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1759484341; cv=none; b=PN92RqhUigK445vVFH0t4+sMetsCr0ar4PO9rbR5ABGc6CK7JFhGxIZVEEaTVzWv9ysJdztGTCogbTkFD0USqpujvHiOW6pnwDW/Aen4U1R++aeJFHO9/bXBvO3d1HH1Nfuzwd4A4mn7CQYYTU0I+OT1AwK1LeA6aj5dI+IHvFd/WwV8cxrDS13Wbc40AMrKIyRwHbHImGycqbNXMk81I8pXLAkLqx/rFT1iik80rKPRe1AnY69aDiDc4OcxDhciLf9M4J3+kjJRcbH+PP3neiNDbOZdQ23Hw9FsUwLdKb99Tc4WPVgtOHoAaCvYzPpKeH2d0FsMLhj+QmDek44lgw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1759484341; c=relaxed/relaxed; bh=OAZW+va4UGdHzF5Qa4jr29c8OlUqqDN5Q2sbkibpf+Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kwMRxWQO26SVNiNRRwYkaCfyOWj1ZpR+w3E54GGvqsmQiS3X2iTxb1WgqKf9SotnbRSnRSIFTThB91N+RudifnRHeH/XUMYcGT5Gqgt0xOXugvh+3yJwlfJnDBREr1XrLbtQoIgG/KVb+gXE/AEnNqKgXUaKyjYabEWCuL1EgErw2mgxZjtqqXYNErLK90Palr444rM4cuhvAmltd1fqjlquTeM+ECPTahPmrBriIuJofYab1oOG9I1BKHqyzMb864+bZRhAn57lmG4w6ZT6sEeTiIj+JlEujyiIuJrOwjoeHxp/muiUGp1HqGIME+zpx0IeklA4PwbRJJATcylekw== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=kevin.brodsky@arm.com; receiver=lists.ozlabs.org) smtp.mailfrom=arm.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=kevin.brodsky@arm.com; receiver=lists.ozlabs.org) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4cdNsJ0PVHz3cYG for ; Fri, 3 Oct 2025 19:38:58 +1000 (AEST) 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 F2D271655; Fri, 3 Oct 2025 02:38:17 -0700 (PDT) Received: from [10.44.160.83] (e126510-lin.lund.arm.com [10.44.160.83]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6FC5C3F66E; Fri, 3 Oct 2025 02:38:24 -0700 (PDT) Message-ID: Date: Fri, 3 Oct 2025 11:38:21 +0200 X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 6/6] powerpc/64s: Do not re-activate batched TLB flush To: Alexander Gordeev , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <8625a1d97dcf4ae499b4bb341e27346f768a7248.1749747752.git.agordeev@linux.ibm.com> Content-Language: en-GB From: Kevin Brodsky In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 17/06/2025 17:11, Alexander Gordeev wrote: > On Thu, Jun 12, 2025 at 07:36:13PM +0200, Alexander Gordeev wrote: >> Since commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash >> lazy mmu mode") a task can not be preempted while in lazy MMU mode. >> Therefore, the batch re-activation code is never called, so remove it. >> >> Signed-off-by: Alexander Gordeev >> --- >> arch/powerpc/include/asm/thread_info.h | 2 -- >> arch/powerpc/kernel/process.c | 25 ------------------------- >> 2 files changed, 27 deletions(-) > Hi All, > > (I trimmed non-ppc mailing lists/people). > > The whole series does not seem to make it, but this patch alone is still > applicable and makes sence, if I am not mistaken. Yes, I agree. I arrived at the same conclusion working on the next version of the nested lazy_mmu series [1]. May I include this patch in v3? - Kevin [1] https://lore.kernel.org/all/20250908073931.4159362-1-kevin.brodsky@arm.com/