From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-113.ptr.blmpb.com (va-1-113.ptr.blmpb.com [209.127.230.113]) (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 79C7C3C4573 for ; Fri, 5 Jun 2026 03:51:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780631510; cv=none; b=qlPIPLyPxvA/xaQcOrbc2IYf0JPiMU/MXei9dekilh6PomUBUZCSw41TkzWCmeiRaW6ePyes8JDB+/lqiraNcSKyvDKRN0RAxqLBJrAQt9VmCxoSfCndDKRgLubCGMtL5pEGp6ZBsm9JzzdaK1xLiOn7gx0RiUGcix7AVavOvms= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780631510; c=relaxed/simple; bh=zSdBSDQMeUE5Fce/G/mqRZzcDcMYd2JhoKYj4Rz6We4=; h=Subject:Message-Id:Mime-Version:In-Reply-To:To:Cc:From:Date: Content-Type:References; b=KLYO4FPwMHtk8DN866f4QABdRsV6/FYgyQ9vMumOd18B40A7mgn31jvvI5K99fUJeh+axtyi0M5weV+fstQ9w0+GFlOuoWrnsGpMc4B6AAbgmWUcGZfMdRmKmNAW4wDSxF4AgWhxPOecc/8UqsriNvFhcvsc8gB6sdSJj5NX6uo= 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=O5XFutB5; arc=none smtp.client-ip=209.127.230.113 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="O5XFutB5" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780631502; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=tvuliiSKNhxLdHuRopfuY3QRvpf4VBq8PY8vObEcEP4=; b=O5XFutB5ml6f7nBdcVMudNZH7b9o/HE5lG9DT96MlyRuG4WOFqZanwA1tqbT0r7P8vNYhp uBkK3QdvpE4lRPUTkl2MX8dvitpF7HapSF8KwlnlZZL3VbIx5BE4MhKMO/ZXKdBho/Rzew +l7/CIDBqBY7NdesQb+PCwJlqsmvoZtGkhDSnmlN4YESyK17NrevUqB/waA4dG/xyvthm/ myLSjqFNt2DZoO+oLAWDSY1yE/Kl9mz04ziIOiVOGnTti3LEuWjBHoBiSPoUCE+bJDOsQk 4Yyx2g/K5n29wzr4yNarK41scD4EddRWcn+Rvy+do6/Hy0V8B3iELp3v3RODtw== Subject: Re: [PATCH v6 12/12] x86/mm: Enable preemption during flush_tlb_kernel_range Message-Id: <9cd743e8-4d60-4a5b-906f-07e4ae82dafb@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 In-Reply-To: <79c1e9c7-574b-4065-ae70-9063fb554b5d@intel.com> X-Original-From: Chuyi Zhou Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird X-Lms-Return-Path: To: "Dave Hansen" , , , , , , , , , , , , , Cc: From: "Chuyi Zhou" Date: Fri, 5 Jun 2026 11:51:20 +0800 Content-Type: text/plain; charset=UTF-8 References: <20260528151338.617843-1-zhouchuyi@bytedance.com> <20260528151338.617843-13-zhouchuyi@bytedance.com> <79c1e9c7-574b-4065-ae70-9063fb554b5d@intel.com> On 2026-06-05 5:21 a.m., Dave Hansen wrote: > On 5/28/26 08:13, Chuyi Zhou wrote: >> - info->initiating_cpu = smp_processor_id(); >> + info->initiating_cpu = raw_smp_processor_id(); >> info->trim_cpumask = 0; >> } > > Doesn't this turn ->initiating_cpu into garbage? It doesn't mean > anything any more other than being a random record of the past. > > I think it's just used for stats, so not the end of the world. But, the > warning is there for a *REASON*. Please don't just turn it off and > ignore the fallout. > > I'm also just generally not sure this is worth it. Kernel TLB flushes > stink. This just makes them stink slightly less. Maybe imperceptibly so. > > Is it worth the churn? Sebastian raised a similar concern earlier[1-2]. The kernel range path does not really need a full flush_tlb_info: kernel_tlb_flush_all() does not need it at all, and the range case only needs start/end. But doing that properly means refactoring the kernel TLB flush path, which would add more churn to this series. Given your concern about whether this part is worth it, I think the best approach is to drop the flush_tlb_kernel_range() preemption patch from this series. That keeps get_flush_tlb_info() using smp_processor_id(), avoids making ->initiating_cpu meaningless after migration, and keeps the current series focused on the mm TLB flush path. If we still want to optimize flush_tlb_kernel_range(), I can do that later as a separate patchset, starting with a cleanup that separates the kernel range/full flush data from struct flush_tlb_info. [1]https://lore.kernel.org/lkml/20260522104818.CbT5fyN8@linutronix.de/ [2]https://lore.kernel.org/lkml/6265669c-d7d4-45a4-a9d2-2f5e884aa7c5@bytedance.com/