From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-112.ptr.blmpb.com (va-1-112.ptr.blmpb.com [209.127.230.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C879F3A901F for ; Tue, 26 May 2026 03:25:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779765943; cv=none; b=QnfsYvEIJ0ip5+8v3fS6DUCUD6yDHAyyU4/XJH99kRWRIjAvATcwh8n+QNMSDqijO2xOOlSwZsLkt//3ME919JN1yaR1+/GAzW+LnEj7BJQIeycxNQcIYcf1EXzNmNrzQJlgLv6Q2dAsMiMndWOmkmdH0lVf7nFYJyT5AOHV1t4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779765943; c=relaxed/simple; bh=jR6emgj6TfNleIxsrWdYLDUC2YjjigVEll3s7bzzIyI=; h=To:From:Subject:In-Reply-To:Content-Type:Date:Mime-Version: References:Cc:Message-Id; b=bC14QK0gA5dNPt2VMG44wBIMkyMmVJj7CxC/RWUV7dbUR9EBkj9iFnLLQFu54LCcA+gzMneep34EwVydo2eX3lDoCC66T60bGNhUlxNhikRx4Hagph/jEGUQ11ceJfuExmjZLdytuKfVAa9J6PlM26hUinVw9n73s+6eE9WwcgQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=miaCz5K2; arc=none smtp.client-ip=209.127.230.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="miaCz5K2" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1779765935; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=vU1K2dikIc9oxllUwLso7vGXthlP0y2OgK/Op51Nrow=; b=miaCz5K2zXXqN9/hElzTbcDINx9r+RjexiDnqyKemg1ZKudajIs0bEMTPvaXTddynAhgH3 flX2y+Twzza3kryq3uFITwmqW5aGVEIk542gkH9hi2cVljG8dZNB+trCoBTAXfQKnhgQV0 UV8kWmMmF2/2hWdvS1/M84qyWAE1mSqchUAtRwiYSDAaLYSrnJ/+0rjN4y4DpC+fiH+5fq Jqgti69CGNOWrzqqZaczZCgIx1Y6ARai6rqhlXiWrGRuT056pt1Hzni/krXeOSMZiFjIdd 4MHFAUR6KwBsoWiJM5JlwkFRPhH5iIYV3JVKbQjOu45P0ciERl6qupwv+5N1aw== To: "Sebastian Andrzej Siewior" From: "Chuyi Zhou" Subject: Re: [RESEND PATCH v5 12/12] x86/mm: Enable preemption during flush_tlb_kernel_range In-Reply-To: <20260522104818.CbT5fyN8@linutronix.de> Content-Type: text/plain; charset=UTF-8 Date: Tue, 26 May 2026 11:25:12 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 User-Agent: Mozilla Thunderbird References: <20260513124524.2569867-1-zhouchuyi@bytedance.com> <20260513124524.2569867-13-zhouchuyi@bytedance.com> <20260522104818.CbT5fyN8@linutronix.de> X-Lms-Return-Path: X-Original-From: Chuyi Zhou Cc: , , , , , , , , , , , , Message-Id: <6265669c-d7d4-45a4-a9d2-2f5e884aa7c5@bytedance.com> Content-Transfer-Encoding: 7bit On 2026-05-22 6:48 p.m., Sebastian Andrzej Siewior wrote: > On 2026-05-13 20:45:24 [+0800], Chuyi Zhou wrote: >> flush_tlb_kernel_range() is invoked when kernel memory mapping changes. >> On x86 platforms without the INVLPGB feature enabled, we need to send IPIs >> to every online CPU and synchronously wait for them to complete >> do_kernel_range_flush(). This process can be time-consuming due to factors >> such as a large number of CPUs or other issues (like interrupts being >> disabled). flush_tlb_kernel_range() always disables preemption, this may >> affect the scheduling latency of other tasks on the current CPU. >> >> Previous patch converted flush_tlb_info from per-cpu variable to on-stack >> variable. Additionally, it's no longer necessary to explicitly disable >> preemption before calling smp_call*() since they internally handles the >> preemption logic. Now it's safe to enable preemption during >> flush_tlb_kernel_range(). Additionally, in get_flush_tlb_info() use >> raw_smp_processor_id() to avoid warnings from check_preemption_disabled(). > > This is a bit odd. That smp_processor_id() is there to catch users with > enabled CPU migration. The only reason is the accounting done in > flush_tlb_func(). This raw_smp_processor_id() is only needed in > flush_tlb_kernel_range() which does not call flush_tlb_func(). This is > only statistics. > > kernel_tlb_flush_all() does not need info at all. > kernel_tlb_flush_range() needs only start and end. > Agreed, I see the concern about changing get_flush_tlb_info() to use raw_smp_processor_id(). The smp_processor_id() check is useful for the mm TLB flush paths. For flush_tlb_kernel_range(), however, the kernel range path only needs start/end, and the full kernel flush case does not need flush_tlb_info at all. One possible way to address this is: - keep get_flush_tlb_info() using smp_processor_id(); - factor the range-to-full-flush decision out of get_flush_tlb_info(), so flush_tlb_kernel_range() can reuse that logic without building a full flush_tlb_info; - make flush_tlb_kernel_range() use a small kernel-only range descriptor containing only start/end for the range case; - make kernel_tlb_flush_all() take no flush_tlb_info argument. That would avoid weakening the smp_processor_id() debug check and make the kernel range path use only the data it actually needs. That said, this does add some extra churn to this patch. Since the main goal of the series is to enable preemption during flush_tlb_kernel_range(), I am also fine with keeping this series smaller if the x86 maintainers prefer, and doing the kernel-range/flush_tlb_info cleanup as a seperate follow-up patch. > Oh well. > >> Signed-off-by: Chuyi Zhou > > Sebastian