From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 7BBF037E2F4 for ; Thu, 19 Mar 2026 10:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773916664; cv=none; b=Oj0p6opS8orv+jal4bMD92tEJoHndSTqrAy4SQxOTPY5elHHC+3HagtaA80IfK+OP/FsetCHje9lVohegiCI1lUtvDu7vMRTzbLtEpjZgoiw/zdqin5QhAbdfidLAb/fjmtTdiC6Aycr3YEW8a9dAhhh/xoTBW6rhAuLc4EMLxg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773916664; c=relaxed/simple; bh=Xyr/dUrYd0dG7DeWsg391uwstktx0YahXT4XGy4LpBc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=FezrOipLEcG31fnDRZIwu/xc+U4tKywfRsKY9Xj/2mnFCommbYONJRq8ZAeUiQxiz87z2TrVIkGGgBBEYf4NS8y1W77gsSruyYD/64a1rDEp3/DSd8BWf4+f+V270tTc2AIda0W3OGn7Onv0K/p0S50yRbhG46WAQjk5eeHDIgs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Y8+fggHO; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y8+fggHO" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4852e09e23dso5974555e9.0 for ; Thu, 19 Mar 2026 03:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773916662; x=1774521462; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rTNIg27KLRR9aYcLDNiNG8Jk/3S5yQxYohfJQvrW8pI=; b=Y8+fggHOmj9Jcua8yD1LGUMhczZH8CRUVwQUIcnhCXtHDHx31DGs+9UcORj9Oj5ilF o3Gn/Z1ttkhA3w5QlnUYHz+jUuXFXKTM2ByG8Hqrgqn6qNjwN5B3bgXqCq2U7b/i9UAG rmv58GPxigiPxxVa6rWZ/zMwDIW0m+y/mJsF6QrUtdAw386qTY58HLoasq28ljZdQyB2 L4Yn5PHtvnqKiWHI6NDcvuOxkRJp8uODjxK+sL78E+q7KFJv2WPpEzR+aGSD0wfvKXgF W/hQOt1epgDgLLhdjYJFEXqU5FnhCK1xnMSs2YTusFF67y5T0kQktuzv6eKokctDyi/F ze+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773916662; x=1774521462; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rTNIg27KLRR9aYcLDNiNG8Jk/3S5yQxYohfJQvrW8pI=; b=lzF5PdgYxhSeqgkD8UK0pmnsEqXTA4nR8Jvc0r0QKzs56HMx6wapOvIuw+z3vSjd2c ytWQ+KPiWhJnyRqstQ0t8tISmJQ8RiYzeEG+Wsw+8pnksQDemJ1XAgTkcXhWzsP9Sc1r Uj+74N5JOzNAF9cY7adsS20tha2AtEDU7TVPcDVTxKYp8UAWN5zz9DqpVujRF8i7bjRo 9le/B3/JJP5piGq0EmBGa0ix+e4WjMUh7nLIWkjaNIs6R8p/DZrSmTR98MWfJKBor2sN HAu4eWIpFQBhuWu550T8j+6c9lswo4eFrq5qi6+uHTOcMnzz/csuU5X1nYk6nofF3j9t md0A== X-Forwarded-Encrypted: i=1; AJvYcCWNPpA3th9ZTJRcR1NA1qdHj/zVc40JOQ8VEh0rnCU5WjnmvjJZSBx+pLgntAQBiGPeWGzDFDXmzMURDDg=@vger.kernel.org X-Gm-Message-State: AOJu0YxbI2BQKYNtQojRH846Qil81ljxwCQ88Szn29YDJBpJPhjk/Ybm CCPXJGZTzGw+xWi3sZXLKJzXKyHC9GsKAmoxCposfb3PPNJ2Tz519I+Q X-Gm-Gg: ATEYQzwQ3zYDO2tZwWm2BcbIEX9kohT4qWbH6WxOPfEfEwZIEIpdRoPfp+UtdW7MsKf agsQTpE0ELYccLzY2vgWUfENo++Fi/JHhAfyWTInNLfzAPg/DWfw9/FZ2pnFi3N8KnsxAjCcpO8 JkFdTkIT+QWBz9g2yby3y3Vg3FaZ8COJrSfbeaeb/Pe85xnrGuKiijeVMuJiuBhYWW4gnNw/Nr+ 2i20BzVHEXzshaYZ2BpVQCORDVmKKDyZkOp4MmsHoscxdl6y6xJEd7kI8j1fpo26Bbu/aLIr+8X t2lPCu3xJI2Xq4IWGS5zVWYD4plUvcao4yM6WELW1J8cTk3h4yPBXKyP7M8G3f1ySXfwEYLk6SJ m+fusmsWvkbr1jV1YKEm9iD04n6FtEN8729et5mAJEmmFY/gOQ/DzZIC+Kew0kk8ZJZxTL3x6sO cujiacMvV+uYcFLlm6v700YgQPRcSPeAklTHXD+I1PXHA= X-Received: by 2002:a05:600c:4507:b0:486:fb69:4960 with SMTP id 5b1f17b1804b1-486fb694a11mr21986575e9.19.1773916661587; Thu, 19 Mar 2026 03:37:41 -0700 (PDT) Received: from smtpclient.apple ([212.59.70.37]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486f5e23874sm69457805e9.6.2026.03.19.03.37.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2026 03:37:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\)) Subject: Re: [PATCH v3 10/12] x86/mm: Move flush_tlb_info back to the stack From: Nadav Amit In-Reply-To: <20260319084929.T6d0DX1P@linutronix.de> Date: Thu, 19 Mar 2026 12:37:27 +0200 Cc: Chuyi Zhou , Thomas Gleixner , Ingo Molnar , luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev, Borislav Petkov , Dave Hansen , Paolo Bonzini , clrkwllms@kernel.org, Steven Rostedt , Linux Kernel Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <167D4B3D-390B-45BE-97DD-FEC1791B3ABC@gmail.com> 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> To: Sebastian Andrzej Siewior X-Mailer: Apple Mail (2.3864.400.21) > On 19 Mar 2026, at 10:49, Sebastian Andrzej Siewior = wrote: >=20 > On 2026-03-19 00:28:19 [+0200], Nadav Amit wrote: >>>> diff --git a/arch/x86/include/asm/tlbflush.h = b/arch/x86/include/asm/tlbflush.h >>>> index 5a3cdc439e38d..4a7f40c7f939a 100644 >>>> --- a/arch/x86/include/asm/tlbflush.h >>>> +++ b/arch/x86/include/asm/tlbflush.h >>>> @@ -227,7 +227,7 @@ struct flush_tlb_info { >>>> u8 stride_shift; >>>> u8 freed_tables; >>>> u8 trim_cpumask; >>>> -}; >>>> +} __aligned(SMP_CACHE_BYTES); >>>>=20 >>>=20 >>> This would work, but you are likely to encounter the same problem = PeterZ hit >>> when I did something similar: in some configurations SMP_CACHE_BYTES = is very >>> large. >=20 > So if capping to 64 is an option does not break performance where one > would complain, why not. But you did it initially so=E2=80=A6 No, I only aligned to SMP_CACHE_BYTES. Then I encountered the described = problem, hence I propose to cap it. >=20 >> Further thinking about it and looking at the rest of the series: = wouldn=E2=80=99t it be >> simpler to put flush_tlb_info and smp_call_function_many_cond()=E2=80=99= s >> cpumask on thread_struct? It would allow to support = CONFIG_CPUMASK_OFFSTACK=3Dy >> case by preallocating cpumask on thread creation. >>=20 >> I=E2=80=99m not sure whether the memory overhead is prohibitive. >=20 > My Debian config has CONFIG_NR_CPUS=3D8192 which would add 1KiB if we = add > a plain cpumask_t. The allocation based on cpumask_size() would add = just > 8 bytes/ pointer to the struct which should be fine. We could even = stash > 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. >=20 > 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.=