From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A857C28488D for ; Thu, 19 Mar 2026 08:49:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773910184; cv=none; b=dfzECzURdMj2/8WEQMzLS5KzJSFvDmBx2ItkyqU+AtPIQZ1yhB8DVnbxAHBnoY5sx+uZr4yqsBzKfspv5cy6W3knG3clhwixk9oeV+fdlrYO3d64GV59abjDkvmEz1JSk1IiupbgbSSRwCqNufN2Am8g8XhEt5zP0hDdGmJN0BU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773910184; c=relaxed/simple; bh=BV3ACzWgbw1th5J4m13peloWMo5djZcwb7ABsQWZCJo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YudaU6bOSt02K1+Nt3x62Z7TX9hNshgI2OE0zBILx2xCFpirn1udufQ9zsS9xyRlezQVNI/9I05XnMqECDoGS9OtjzAysVGnoMd2feMQzOu/U4mtQNpFtYQMhw7ZlEWzINGEtnbRoxUVGHmLiPZ5tAUOFFYUaORbhXjrlHThTjM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=rOdPFJwh; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=BV9Ivfgi; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="rOdPFJwh"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="BV9Ivfgi" Date: Thu, 19 Mar 2026 09:49:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773910171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c2IUlp28pLP+rluE61V3U+WN6uA/iucU0vI8NXUhQZ8=; b=rOdPFJwh2rILqzC/he3AnplAhiFNk+PhRHnSZcCfELSo6wx64AOOMDDxkBn2OlehWXVhsY YQ2pqfBBs8JCovPNIhW0AWyve28Px6DE05RA9ldcKu/7Tg3J7VK8U8gNd3SGsNQgQ+W0u8 vZd0RkAMFdxSb3yaIfigRCa1249YeTKVg8syK/+Pnm/yCDb1+JDMJHsRnwb7TzBf5pC4Pt GO6FfnSpVTwP0nwTtL6oJ/kjBgXbdQQquAd+dnYRrGOH6IWEQXoOUWhhlWKpvqmeQx8r0F iQfSDOiq6tLU1+95hmRvTC512OYNCFDyZoMxFVKqt9m8BjKDPTuhVrn59mCaYg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773910171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c2IUlp28pLP+rluE61V3U+WN6uA/iucU0vI8NXUhQZ8=; b=BV9IvfgigoACBT0RjVIKvjuOVfuzRPonyl6kyAZW5b9pZdLu0yF7BFdku3oZi5TQhCyIOV 8t7i4LqYZOHcfGDw== From: Sebastian Andrzej Siewior To: Nadav Amit Cc: Chuyi Zhou , tglx@linutronix.de, mingo@redhat.com, luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev, bp@alien8.de, dave.hansen@linux.intel.com, pbonzini@redhat.com, clrkwllms@kernel.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 10/12] x86/mm: Move flush_tlb_info back to the stack Message-ID: <20260319084929.T6d0DX1P@linutronix.de> 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3A5D6EAA-E20D-487E-987C-BA88B98820BD@gmail.com> 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/tl= bflush.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 Peter= Z hit > > when I did something similar: in some configurations SMP_CACHE_BYTES is= very > > large. 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 > 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=99s > cpumask on thread_struct? It would allow to support CONFIG_CPUMASK_OFFSTA= CK=3Dy > case by preallocating cpumask on thread creation. >=20 > 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 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. The flush_tlb_info are around 40 bytes + alignment. Maybe we could try stack first if this gets us to acceptable performance. Sebastian