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 491C73033E6 for ; Fri, 24 Jul 2026 03:09:30 +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=1784862574; cv=none; b=U+lX1nmOZNTfxQkCobKxnY6ToqBQa2FiKXO+FP51WFpGiRfA71TGEviHKDMNK6eiYvCEsH5K6e4xoQphLJYUOO8e5iXLX3ZjR12qYM36xuadaK5iyucRlc79GYAXlXbyOsF8fJjenfP9jzYFKAsrPdPctqSUoDsuKaHe0KGsTtA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784862574; c=relaxed/simple; bh=b/4AEEC0nqI7loj4FsV3Z65xconG+TQPssq5SIvz6aU=; h=From:Mime-Version:In-Reply-To:Cc:Date:Message-Id:References:To: Subject:Content-Type; b=o/ed/+qCAMQ6ZhsKtkcN9Sm7t0SsnQ5/TlEy6TPmvVd/MQ8HCkckfrQpDun3G+ucSpy34cgCQicCW64IJ8Fn59lrRy6lDn8yH1tUG4oce2Rmfc3BPFXNtfx8di0J24sjGdG4j4+HlNwVY5Qs+7rUQcyXXE4OCZHr48GXfFCRomA= 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=qAL4Qd1Q; 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="qAL4Qd1Q" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1784862560; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=7h9JfQFn66X6dvrhQ7GsNzfJ16BEdfFGglGGLVVuIIY=; b=qAL4Qd1Qv6PhC+DzTQHo0YfglDMHQW6PQooU+zJ58Ap6uA9Xg47Vt8dS5OUBwGvCzW0OmY YHu9mC7nhIKziptXEISAUoKQaEsp76U6NLkkpQf/1IPFuAR57HakgzTinIeohb1jazgzwB 1OpK5z1F7My62DvvhMf8CNeA0fxVxrL8FmmhZ21hs3uSd4AnYHFJLOzCWJhc05KRNJrH/S bTPE05K1vVkI8SzXp0Q+ItSCPaeDsOwW6/Pp5NW2Mb/RIVvWgodK383jFfhRuQ52OJtrvD +Zvy5C1t7G3mJy33HZbEAeQGWPK1RM82usIP5KUu6mKRgo2YB/0mcEXIT3vhpg== From: "Chuyi Zhou" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 User-Agent: Mozilla Thunderbird In-Reply-To: <20260723192657.GBamJrAcb_TCH5Ubog@fat_crate.local> Content-Transfer-Encoding: 7bit Cc: , , , , , , , , , , , , , Date: Fri, 24 Jul 2026 11:08:56 +0800 Message-Id: <232b30b6-f555-4ae2-982d-b59172fcbb35@bytedance.com> X-Lms-Return-Path: X-Original-From: Chuyi Zhou References: <20260709122933.4021501-1-zhouchuyi@bytedance.com> <20260723192657.GBamJrAcb_TCH5Ubog@fat_crate.local> To: "Borislav Petkov" Subject: Re: [PATCH v10 00/14] Allow preemption during IPI completion waiting to improve real-time performance Content-Type: text/plain; charset=UTF-8 On 2026-07-24 3:26 a.m., Borislav Petkov wrote: > On Thu, Jul 09, 2026 at 08:29:19PM +0800, Chuyi Zhou wrote: >> In our production environments, latency-sensitive workloads (DPDK) are >> configured with the highest priority to preempt lower-priority tasks at any >> time. We discovered that DPDK's wake-up latency is primarily caused by the >> current CPU having preemption disabled. Therefore, we collected the maximum >> preemption disabled events within every 30-second interval and then >> calculated the P50/P99 of these max preemption disabled events: > > Out of curiosity, can you run your workloads on AMD Zen3 and newer which have > TLBI support (this does away with the TLB flush IPIs). Do you see any > improvement there? > > Thx. > Hi Boris, Thanks for the suggestion. If I get access to suitable AMD Zen 3 or newer production machines, I would be happy to evaluate this series there. On a system where X86_FEATURE_INVLPGB is enabled, I would expect the direct benefit on the TLB flush paths to be smaller. For an mm which already has a global ASID, flush_tlb_mm_range() uses broadcast_tlb_flush(). arch_tlbbatch_flush() also uses invlpgb_flush_all_nonglobals() directly for pending unmaps. Neither path waits for remote TLB flush IPIs. Those paths still have to remain on the CPU which issued INVLPGB until TLBSYNC completes. Consequently, this series does not make the INVLPGB/TLBSYNC section preemptible. The benefit is not necessarily zero, though. A global ASID is assigned opportunistically, currently for an mm active on at least four CPUs. Before that assignment, flush_tlb_mm_range() can still fall back to the IPI path. The same applies when INVLPGB is unavailable or disabled. There is also an architecture-independent effect. The generic smp_call_function*() changes keep the caller pinned only while selecting the target CPUs, preparing the per-CPU state, queueing the callbacks and sending the IPIs. The synchronous completion wait can then be preemptible when the caller's context otherwise permits it. In particular, smp_call_function_many() and its wrappers no longer rely on an outer preempt_disable() merely to protect the call-function machinery. This benefits non-TLB synchronous IPI users as well. It also provides a basis for auditing other call-function IPI users and removing outer preemption-disabled regions which only existed because of the old requirement. Callers which protect their own per-CPU state would, of course, still need their local protection. The data in the cover letter came from real production workloads. The long-tail latency depends on the workload mix, interrupt-disabled sections on remote CPUs and the number of target CPUs, so a short local or synthetic test may not reproduce it accurately. A more meaningful experiment would be a controlled, long-running comparison between the baseline and patched kernels on comparable production AMD Zen 3 or newer machines. We could then collect the same 30-second maximum preemption-disabled distributions and DPDK wake-up latency over a sufficiently long period. That would also help separate the remaining INVLPGB/TLBSYNC latency from latency caused by other synchronous IPI users. If I have the opportunity to perform such a production comparison, I will report the results. Thanks.