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 035E640DFC8 for ; Thu, 19 Mar 2026 13:41:59 +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=1773927722; cv=none; b=Rc18dCz4ULKZqYYEWhHSNQ8JrXlTRCgA3JJwYAWp5pAgR3PEyu+1Fzej+mz6HRP3Nzk5+ltGDDh1VdgpUzr8hYxHN3TxEBHSkpwwYRXeVXjNWEaw3hDitY8q96R3nD4tyVTmzGQC6o25q1lYwMGTDDvCPUd40SMoBTh8NJyOYwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773927722; c=relaxed/simple; bh=OeRf9PhWnAPaKp1m+j3JUIu8Z/+OQAf1cNxiAQhFOXA=; h=Content-Type:In-Reply-To:Date:References:Message-Id:Mime-Version: Subject:From:To:Cc; b=fFr625gZzqZ+s/ALq+gSp/LUEnmWRqxSYN/9/ea6nmCXjoj7yAqK2kRMVF6Tf8FZ1agucx9dJIXjKSt/f9BqGC0ZHpoBDVakVFf6f7Ofy2bY280mL/91JClKQfwmFPDUZxiseuSTVCaNpkMBoiBdNjEhru9SWovBdnjucwKanOI= 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=qDLvkGAg; 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="qDLvkGAg" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1773927708; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=dDWVikz5oP56zhVvoEOQqpjDDO3fRTWJV9BTVA7I/1Y=; b=qDLvkGAg2gJFHhsAZ8Y7fRP39pTSm7c/ZKNaHE1iyHvmpE1Mvp2vbPGd+8yEVo2OOm4b0v cqGl9FCOCPuNQ6SLxnYgrNtEat8zvRLktgfZXtJYMT5shuJwAtAn8Cq2Jr3y56b0wNnKJ8 kF4KF5pCgMIAGsc9BayVOG19+nE7xhCOITM0hAC+9YL1XO1EIGit38LLyAQJ7U6MAjw9fV RC/V+Syaf5UjfZJmdbIRk3SXsnT2sDfrogiXXm6R/MiJajTcIELypF9fzAfVlZI0oCmGjS vXolsVxbQLf/Az0ZKnIktAvRxQhNqyYXsbPo6OPkaFbUr3NBy+XuUdZ9ujgOtA== X-Lms-Return-Path: Content-Type: text/plain; charset=UTF-8 In-Reply-To: <20260319105827.Bx4E3nUN@linutronix.de> Date: Thu, 19 Mar 2026 21:41:28 +0800 References: <20260318045638.1572777-1-zhouchuyi@bytedance.com> <20260318045638.1572777-11-zhouchuyi@bytedance.com> <20260318172143.ICooJ3-U@linutronix.de> <44F4BED1-D09A-40B3-BB2B-E2AFB0AF8D0D@gmail.com> <3A5D6EAA-E20D-487E-987C-BA88B98820BD@gmail.com> <20260319084929.T6d0DX1P@linutronix.de> <167D4B3D-390B-45BE-97DD-FEC1791B3ABC@gmail.com> <20260319105827.Bx4E3nUN@linutronix.de> Message-Id: <7f4fd9bf-8e8c-44ec-a0e7-64e21abc8d13@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v3 10/12] x86/mm: Move flush_tlb_info back to the stack X-Original-From: Chuyi Zhou From: "Chuyi Zhou" User-Agent: Mozilla Thunderbird To: "Sebastian Andrzej Siewior" , "Nadav Amit" Cc: "Thomas Gleixner" , "Ingo Molnar" , , , , , "Borislav Petkov" , "Dave Hansen" , "Paolo Bonzini" , , "Steven Rostedt" , "Linux Kernel Mailing List" Hi Sebastian, On 2026-03-19 6:58 p.m., Sebastian Andrzej Siewior wrote: > On 2026-03-19 12:37:27 [+0200], Nadav Amit wrote: >>>> Further thinking about it and looking at the rest of the series: would= n=E2=80=99t it be >>>> simpler to put flush_tlb_info and smp_call_function_many_cond()=E2=80= =99s >>>> cpumask on thread_struct? It would allow to support CONFIG_CPUMASK_OFF= STACK=3Dy >>>> case by preallocating cpumask on thread creation. >>>> >>>> I=E2=80=99m not sure whether the memory overhead is prohibitive. >>> >>> My Debian config has CONFIG_NR_CPUS=3D8192 which would add 1KiB if we a= dd >>> a plain cpumask_t. The allocation based on cpumask_size() would add jus= t >>> 8 bytes/ pointer to the struct which should be fine. We could even stas= h >>> the mask in the pointer for CPUs <=3D 64 on 64bit. >>> On RT it would be desired to have the memory and not to fallback to >>> waiting with disabled preemption if the allocation fails. >>> >>> The flush_tlb_info are around 40 bytes + alignment. Maybe we could try >>> stack first if this gets us to acceptable performance. >> >> I know it 1KB sounds a lot, but considering fpu size and other per-task >> structures, it=E2=80=99s already almost 6KB. Just raising the option. >=20 > Sure. We might try allocating just the cpumask while allocating the > task_struct so we won't do the whole 1KiB but just what is required and > we might avoid allocation if it fits in the pointer size. >=20 > Sebastian IIUC, you mean something like the following? diff --git a/include/linux/sched.h b/include/linux/sched.h index 5a5d3dbc9cdf..4222114cd34c 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -927,6 +927,8 @@ struct task_struct { unsigned short migration_disabled; unsigned short migration_flags; + cpumask_t *ipi_cpus; + #ifdef CONFIG_PREEMPT_RCU int rcu_read_lock_nesting; union rcu_special rcu_read_unlock_special; diff --git a/kernel/smp.c b/kernel/smp.c index 47c3b057f57f..f2bbd9b87f7f 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -112,6 +112,29 @@ void __init call_function_init(void) smpcfd_prepare_cpu(smp_processor_id()); } +static inline bool can_inline_cpumask(void) +{ + return cpumask_size() <=3D sizeof(cpumask_t *); +} + +void alloc_ipi_cpumask(struct task_struct *task) +{ + if (can_inline_cpumask()) + return; + /* + * Fallback to the default smp_call_function_many_cond + * logic if the allocation fails. + */ + task->ipi_cpus =3D kmalloc(cpumask_size(), GFP_KERNEL); +} + +static inline cpumask_t *get_local_cpumask(struct task_struct *cur) +{ + if (can_inline_cpumask()) + return (cpumask_t *)&cur->ipi_cpus; + return cur->ipi_cpus; +} + static __always_inline void send_call_function_single_ipi(int cpu) {