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 10AB2168BD for ; Fri, 5 Jun 2026 02:57:20 +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=1780628248; cv=none; b=MgvWN2EEWErztlskXj8YcQ1GMHu71c9QKFHmObq7noDJqO6d77gWUqh4ykqeDn8xLVueoGNPLti0+YGFAehvhTtbwvTGQrK2Q2M33662IPOfLxKZnVMstKdu4wX9dBZah8NhYLXjDgn5G30d4I6NKwdXz87SNmcdpc1wrZTAvDE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780628248; c=relaxed/simple; bh=Y7cGIA+qc2s6gNu/tHBwIkKo3K7ZRG9XNMmHSTFDYmo=; h=From:In-Reply-To:References:Subject:Mime-Version:Content-Type: Message-Id:To:Cc:Date; b=Kc337ewljk9KgKtTVG3A6VSwVnYRvbqBLI/erPY3AAppXS4OeWSo1UCi78DYtbb6FCIkVVDKIdcPt2t7FU6i3PbBWRmr8OGiFH2RXACDVlRizWCLeLI0Z85Pq1nlT+hZP5Tl52JzKfviH1yYPbUaPPd+0BiJR/bYcAPeBjZaDSw= 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=caEW2bBz; 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="caEW2bBz" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1780628121; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=mh6iYb4AMzRq9kUyRmJAzl7LftednehsnyheQxGbS/U=; b=caEW2bBzeEJq4HNZoJIH+PO052arx62sfNIZO3zw/69sSC89k/q48wDSwnaQS68yAu8h2J /ioW7LHIWmJHEfI6WzO6zNEgoyny7ClRdo98/cEqwT9va1ld8hbD4Dc5L2/WOryQtW37tN lIym4bxxJq9N34bqChZwfXsqN3nKTbk4hUSIWJhqpxXpmmKFYboxHSxYd1337rQoiB36mX 6PClZAOJI5L3MqgCGXc9havc2ZyciU7npJxA9BQiwF3XkhdUctvrARAUKFBuU2i1Yis/EJ KQlpp80OJOCHwl9csZckaNjz5NUJabADjWJOkc6xdoQnoWaYPbTsEoIMLtWKIA== User-Agent: Mozilla Thunderbird Content-Transfer-Encoding: quoted-printable From: "Chuyi Zhou" In-Reply-To: X-Lms-Return-Path: References: <20260528151338.617843-1-zhouchuyi@bytedance.com> <20260528151338.617843-11-zhouchuyi@bytedance.com> <7A89193C-45D6-4118-87D5-9DC08EBFC11D@gmail.com> <2d78085c-0d5f-4476-868e-23c763830fe3@intel.com> Subject: Re: [PATCH v6 10/12] x86/mm: Move flush_tlb_info back to the stack 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 Message-Id: X-Original-From: Chuyi Zhou To: "Nadav Amit" , "Dave Hansen" Cc: , , , , , , , , , , , , Date: Fri, 5 Jun 2026 10:54:53 +0800 On 2026-06-05 5:21 a.m., Nadav Amit wrote: >=20 >=20 >> On 5 Jun 2026, at 0:16, Dave Hansen wrote: >> >> On 6/4/26 14:11, Nadav Amit wrote: >>> >>> That's what led us to move flush_tlb_info into a per-cpu struct (preemp= tion >>> was disabled at that time, so there was no trade-off). Now that Zhou cl= aims >>> that disabling the preemption is a pain-point, and therefore does not w= ant >>> to set flush_tlb_info per-cpu, the solution we've landed on is to put i= t back >>> on the stack - avoiding the need for a single flush_tlb_info that depen= ds on >>> preemption being disabled =E2=80=94 while limiting the alignment to 64 = bytes so the >>> stack doesn't grow out of control. >> >> OK, cool. That's great info for a Link: tag. It also seems like you're >> happy with this, so would a ack/review tag be appropriate to provide? >=20 > Ack tag is fine with me (there=E2=80=99s already suggested-by tag). For r= eviewed-by > I should look a bit more thoroughly... Thanks Dave and Nadav. Yes, I agree the changelog should be reworded. I did not mean to question Nadav's original patch or the benchmark methodology. The per-cpu storage made sense when preemption was disabled, especially=20 after the earlier stack-growth issue with cacheline-aligned on-stack=20 storage. I will update the changelog to describe that history explicitly: the old stack-aligned version could grow the stack too much on some configs, which led to the per-cpu storage, while this series needs to remove the single per-cpu flush_tlb_info dependency as preparation for shortening=20 the preemption-disabled window. The proposed compromise is to put it=20 back on the stack, but cap the alignment at 64 bytes. I will also split this into smaller patches in v7: 1. refactor the flush_tlb_info helper so initialization can use caller-provided storage, without changing the current per-cpu storage; 2. add the capped alignment for struct flush_tlb_info; 3. move the actual flush_tlb_info storage from per-cpu back to the stack. Nadav, thanks for the ack. I will add this in the next version.