From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-114.ptr.blmpb.com (va-1-114.ptr.blmpb.com [209.127.230.114]) (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 9F54834889F for ; Tue, 16 Jun 2026 15:36:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.114 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781624221; cv=none; b=td6gJwwfRnzgRRPUcBl/rCLJsH7GpeGodkGDlzhRJYpIXqz/ZAskWCptPS11EB3AXrhaPRp35NNlpXvaO2wOouknbBy+Rav8bZxd1E7eWe38E0ItCMBUK3RteevLnZMfoHXSms4IT6E6yOpuqK+cmUBKchwKS/vVwPRvwne3Zgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781624221; c=relaxed/simple; bh=IY/YLHNy+X7Qe3540zoYe95k6Au/4XTZ/Ay7oGdjGh8=; h=Subject:Date:Message-Id:References:To:Cc:Mime-Version:In-Reply-To: From:Content-Type; b=GwDmKBz0NDBcMoOiJfxnPC7hxE0rOO82DAW0IKtYINOvHMgFV8LT6kgGEjkFprHApCejaWUMVOYlsn4rLlLHtZpi0VAgqRfcd7LvZBYc93nMlHTTEYkz+drQdQXrvRu3ku8RhIrkS3oP4EOX0+WJYzHfF2GijAuoi9+EV3JOESw= 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=JYDTFo8A; arc=none smtp.client-ip=209.127.230.114 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="JYDTFo8A" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1781624214; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=vTjzlxMTz7HZHbVF7v+TGf3iZMftsjYKIsa8QWh/088=; b=JYDTFo8A+kaeFe5VsKkE3CB4q8yZCs3tfRIMGmbv0K+d1t4Zu+VXPi1TAtbZVhKj3oQSrf jFYzfZlyvR7o0f3++BUWRjka15gbWSxjiYJK8dVrFqeZAyORNoiwNe1zv/aI1b9rrhDOTk 5drLAECw9xbSKYbpQ9D9JgrzXUuwQ6Cg6detgAUn0YZRCIZJTiD85r/rOxO0BwLDsXt3TM iVYi49z0A3VT2zGA33iOTLf9H+9g+f1DPbIWhAqaqrmoWmaDJGl4LZLGyl9K+U4dVMKu7I 5beTEUAcyGvs51wkRwD9Gf729HG9W5eX2mc3QrLMtsh3E9VnLXMQm/C4BjpP5g== Subject: Re: [PATCH v8 11/14] x86/mm: Cap flush_tlb_info alignment at 64 bytes Date: Tue, 16 Jun 2026 23:36:23 +0800 Message-Id: <07e24b43-ada5-4d87-bf27-29871e00fba9@bytedance.com> References: <20260616111127.966468-1-zhouchuyi@bytedance.com> <20260616111127.966468-12-zhouchuyi@bytedance.com> <20260616132036.A4j5OW-H@linutronix.de> To: "Sebastian Andrzej Siewior" Cc: , , , , , , , , , , , , , Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 User-Agent: Mozilla Thunderbird X-Original-From: Chuyi Zhou In-Reply-To: <20260616132036.A4j5OW-H@linutronix.de> X-Lms-Return-Path: From: "Chuyi Zhou" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-06-16 9:20 p.m., Sebastian Andrzej Siewior wrote: > On 2026-06-16 19:11:24 [+0800], Chuyi Zhou wrote: >> A stack allocated flush_tlb_info should keep cacheline alignment to >> avoid the regression that motivated the per-CPU storage, but using >> SMP_CACHE_BYTES directly can make the stack frame grow excessively on >> configurations with large cache lines[1]. >> >> Add FLUSH_TLB_INFO_ALIGN and cap the type alignment at 64 bytes. The >> existing per-CPU flush_tlb_info instance remains >> DEFINE_PER_CPU_SHARED_ALIGNED(), so its per-CPU shared-cacheline >> alignment is unchanged. >> >> The capped type alignment matters once flush_tlb_info is moved back to the >> stack by the next patch. >> >> link[1]: https://lore.kernel.org/all/tip-780e0106d468a2962b16b52fdf42898f2639e0a0@git.kernel.org/ > > I suggest to incorporate a reference such as > > | See commit 780e0106d468a ("x86/mm/tlb: Revert "x86/mm: Align TLB > | invalidation info"") where the usage of SMP_CACHE_BYTES led to 320 bytes > | stack consumption. > > This [1] and link and such is just forth and back. > >> Signed-off-by: Chuyi Zhou > > Other than that, > Reviewed-by: Sebastian Andrzej Siewior > > Sebastian Thanks, I will fold this into the changelog. I will replace the indirect [1] reference with an explicit reference to commit 780e0106d468a ("x86/mm/tlb: Revert "x86/mm: Align TLB invalidation info""), and mention that using SMP_CACHE_BYTES led to 320 bytes of stack consumption.