From nobody Sun Jun 14 02:11:55 2026 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 6739D3FE65F for ; Wed, 29 Apr 2026 17:36:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777484190; cv=none; b=NzFMPWexNF/OEDaRS4sWvu+cJxCktPcqkFjT+vBrhasZFON9unOn75Zv10SyK6JOeRDajd1kvzF4iC2LlXkmZhRaFGZ+rMILkw+nVHJVnE+JDfL7kkIkLaxsJDYwEqKGvUXdidmrekhhZ/didMOQOQK4486vgh9gCrvRBNeSLy8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777484190; c=relaxed/simple; bh=JF9ZFidUicRlAcCbQncK8HqM7MrMRoNs5Wpf957QLtY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GiGVZbti9eXcCN9LqAvJ5ci0id5s9xglDw441/2Vw0FYmYj3P65/qPvdEAayiK1njej1uAtzB7vAEwIxDKMooklEWxQUPVobYt2PKplngYcoXtH+436qTKxbYRzvs7UXF+mv2IJqITD6VUZ6JpedXAmuWVKsv7cfcXslL61J+2A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org; spf=pass smtp.mailfrom=wbinvd.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b=G3alGpCX; arc=none smtp.client-ip=74.125.82.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b="G3alGpCX" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-2ed0a45e970so62113eec.1 for ; Wed, 29 Apr 2026 10:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1777484188; x=1778088988; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GBZR1vQ+XW/8g2ZcPEJAJuQiQZIb8i4vtQDaXQ6Bcbc=; b=G3alGpCXTC4PYalTq+Fo21uZ32CZU6PDTXzxy+cxXIV47EQXWOYkEeYmddSgNZZssX vvIZ4zkZbD1UZIyO8ftgsw1TRUh5HkblRC774ldggAPRnHVRoDkOpkFEi1xkAirXApYj D/ywPM+ShQVrgkv6QYRFPTsImlU7NQnY4ACcyc1K/U8N+EtkQdG+BerUgaBLhFakxx7S VozUuSPoume7CCZf44QERNONC2Hcaw5XtDDajiXnBZTQbrgVnGvbB5CcsK7hD80n8zK2 OgTxEjgAF4ZS3HDRkX0ohZmWkmt+KRvW1j7DKKdRKcQpco/HIwPcbIre56N+tJ41Sv7J VISg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777484188; x=1778088988; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=GBZR1vQ+XW/8g2ZcPEJAJuQiQZIb8i4vtQDaXQ6Bcbc=; b=PZ8eGN0ejEf/rFSXePttifU0teSINjw4SymEhXqLI3poTzwwzL3XFVEYB/0RFRZLng IxGw0BjepBgXgE7z0P49XKwzc6UhIqn3Y9vpGW7mgGcmzSYy5FTHjXXK5tI23WowmbDj 9C/+cbA+71GQjlQJHUNrk2UIU5GyVJrr5j0JGqH6FWQpd7P5RlHjNTTr08dYjvc7vR0/ tmxocuot85xX8hdps9oHLNdEfP4XhiEt4vg8kXyaWgZ99ZEv5RTtuuw3jkudSkhmetsn ghpAoEBzo4hGdK9gzV4JYms1FBnmi6TdSsSBnSseqo5IuWq92pnobc+T2ld8ieRQGNLn jO4A== X-Gm-Message-State: AOJu0YzcdrkaN1uO0cyHfPhG+ud72zrpQmMciVG+BfBj39tA2ByIGMKh GLfegXDPoHUWXfG9MXBc0HaJgLDMCU0luJRNULL9+rfdBOJ+76SSTsQwKC4Lq2jbbAAkh3H/sRz PRpNX1QY= X-Gm-Gg: AeBDieukq6jGOHKdqC4y71N1ka0ijMZMPypPO9ireI4WrH5Uk2tK2Ob8HSn58prs9AS HSAkL0n9eoP8gaU0xkP2U69nHkzhnjdWfYgVT3n+sVaeQC8k3gsBiIQU8LEqyw3JZf4Xt5gjcDM TYx4F322waihGAIo2fZIz22kkLWFxjZQRvWMjPWPrmBnQeqI30O8fSGXJl0p+PixMp66Kk7WWsd feCJ/FBJIdsn1FoPBAAUrrWnz/zJ7jRlrIR3eX2krHiTwAappH5C4kuRM2TFwL8oEkrVLqf+/rJ ChpF39q5iEM08UGF4f2lCruYLM8L0hjKXoetqvK2HNxe30UbdLidg/VL9j5u90fCzprHiADoSYD YO7lDS0Euc1ItgIqDnjCBtSeVV2gW6DYqlOWxj9dP9bJvZ87oDYlXWXw4ilKJZY5kGubt4974l3 8lD6C47FsWFxCzIOM/L7bqigJ7ouzj9xQs3W27 X-Received: by 2002:a05:7300:1908:b0:2e6:ff79:e344 with SMTP id 5a478bee46e88-2ed09fbb95bmr3969265eec.9.1777484188387; Wed, 29 Apr 2026 10:36:28 -0700 (PDT) Received: from mozart.vkv.me ([2001:5a8:468b:d015:eadf:43ff:5bad:d931]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2ed1c09c6e3sm2899087eec.25.2026.04.29.10.36.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 10:36:27 -0700 (PDT) From: Calvin Owens To: linux-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, x86@kernel.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Andi Kleen Subject: [PATCH v2 1/2] perf/x86: Avoid double accounting of PMU NMI latencies Date: Wed, 29 Apr 2026 10:36:10 -0700 Message-ID: <303ba711a576cc016d349a132548237601d8b7b8.1777483573.git.calvin@wbinvd.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Because NMIs always poll all handlers, calling perf_sample_event_took() unconditionally in perf_ibs_nmi_handler() and perf_event_nmi_handler() causes two latency numbers to be fed into the exponentially weighted moving average for each NMI on AMD machines, one of which is much smaller than the other: <...>-70985 [029] d.Z1. 13311.704313: nmi_handler: perf_event_nmi_han= dler() delta_ns: 6732 handled: 1 <...>-70985 [029] d.Z1. 13311.704317: nmi_handler: nmi_cpu_backtrace_= handler() delta_ns: 1673 handled: 0 <...>-70985 [029] d.Z1. 13311.704319: nmi_handler: perf_ibs_nmi_handl= er() delta_ns: 2064 handled: 0 This can bias the average unrealistically low, in this case because the latency of perf_ibs_handle_irq() doing nothing is averaged with the latency of amd_pmu_v2_handle_irq() doing real work: # bpftrace -e 'kprobe:perf_sample_event_took {\ printf("%s: cpu=3D%02d sample_len_ns=3D%d\n", strftime("%S.%f", nsecs),= cpu(), arg0); }' Attached 1 probe 02.836860: cpu=3D17 sample_len_ns=3D7775 02.836871: cpu=3D17 sample_len_ns=3D1492 // avg=3D4634 03.042803: cpu=3D20 sample_len_ns=3D4298 03.042810: cpu=3D20 sample_len_ns=3D1152 // avg=3D2725 03.204410: cpu=3D27 sample_len_ns=3D6973 03.204420: cpu=3D27 sample_len_ns=3D1302 // avg=3D4137 03.622364: cpu=3D00 sample_len_ns=3D5270 03.622371: cpu=3D00 sample_len_ns=3D992 // avg=3D3131 Avoid the problem by only accounting the latency of the handler which actually handled the NMI. Fixes: c2872d381f1a ("perf/x86/ibs: Add IBS interrupt to the dynamic thrott= le") Reviewed-by: Andi Kleen Signed-off-by: Calvin Owens --- Changes in v2: * No changes except tags: added Andi's Reviewed-by. arch/x86/events/amd/ibs.c | 6 +++--- arch/x86/events/core.c | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c index e0bd5051db2a..b451a1b2c9ad 100644 --- a/arch/x86/events/amd/ibs.c +++ b/arch/x86/events/amd/ibs.c @@ -1599,10 +1599,10 @@ perf_ibs_nmi_handler(unsigned int cmd, struct pt_re= gs *regs) handled +=3D perf_ibs_handle_irq(&perf_ibs_fetch, regs); handled +=3D perf_ibs_handle_irq(&perf_ibs_op, regs); =20 - if (handled) + if (handled) { inc_irq_stat(apic_perf_irqs); - - perf_sample_event_took(sched_clock() - stamp); + perf_sample_event_took(sched_clock() - stamp); + } =20 return handled; } diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 810ab21ffd99..d1c7612e2e5b 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -1814,7 +1814,8 @@ perf_event_nmi_handler(unsigned int cmd, struct pt_re= gs *regs) ret =3D static_call(x86_pmu_handle_irq)(regs); finish_clock =3D sched_clock(); =20 - perf_sample_event_took(finish_clock - start_clock); + if (ret) + perf_sample_event_took(finish_clock - start_clock); =20 return ret; } --=20 2.47.3 From nobody Sun Jun 14 02:11:55 2026 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.173]) (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 EBF2441322E for ; Wed, 29 Apr 2026 17:36:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777484192; cv=none; b=DLBF0umW/u9077494FTFcHrvGURoxqr1AkmXrrgarONBPMbBKVtOB3Z/EIKbg8S6HxwfRrZhgehtYbpz7Mv4pEv17/B/ERqZWPwCT7yMl+nF8gz26FIn+3bILEN0yGPiMnN1mcV4f2hfaecJ7fFoYZ6xDI7YbEG0qW1i/HElStM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777484192; c=relaxed/simple; bh=uwU4DYRhKwepclGtKTM4yCcHG3JfSXJYqKIVcGBiSgI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZeldYTxcCY+qsyIq7Y7FGe3yNyrqzriT4C4rH8b9j7UAU1oMVGbwb+xRNfjog5TdLMruNHbt61P8+uk9tUr1/wgKt7jQrA30X2nYyEur+Qo/O9Blrdr8GbvklkTrrzu11eo87l0853qV8fL7YUqdWbKk/acAkgyiuLsWPmemjEw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org; spf=pass smtp.mailfrom=wbinvd.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b=b4w8g0eJ; arc=none smtp.client-ip=74.125.82.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wbinvd.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org header.b="b4w8g0eJ" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-2c15849aa2cso114109eec.0 for ; Wed, 29 Apr 2026 10:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1777484190; x=1778088990; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aO8WG8Socwj3Htukhg7X7ENz50SwDAgrsCID6h8CJjo=; b=b4w8g0eJImd0dZY3fyh7QW19+BjX2Wh/dZLKtGhtHdW+a6PmwYuRVsvI7TKiUSwFU6 QegyEgwZmRgtobyewsQkZNrpz4OffV6QPxBKKQdPvBab96rT52NFBzqtxbtn4xkhizvd J4ysok7/UrBmOGFCnBvru/W6isbOax5VD33zsVMXjrpx31FEipHa+z+yflMBg+Q/NKQl i+S8nVPy5kUQ2lPEw71NnJwoJSBQ48HJAxlIkhfKikYRnHPlUZEoEF9O2NUufEgOzZ34 SYtNOJufmtt+wLmlxGKuEyVDcbjdZB5kcMNoXzrkCrXM294iKM9oZILEW13AzxXc0zDM ldLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777484190; x=1778088990; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=aO8WG8Socwj3Htukhg7X7ENz50SwDAgrsCID6h8CJjo=; b=UyT7jq6JwqboFtwAkJRBYfYkZa6zs0zTG7dyMnsKRoP2lMf4BcxFnscusXL+iBraGq EutPp/pSrDWTIP4I2vMnfnMrp6VEE2/HAAr7k4p3lgQbrM098ya2MBlNdvx2Tscg1gHP GFGDhCJNwXMWscHQ7WzmacbXMNM2PRCZZzI8xjiwxSBbe8PTOgyBVmNEWGAoGdLN26dB 8ZGGQUBBR4K4ZgXZ5clz/S9pWTjizxYe2viPvmyY0I/8hL2aGJlt1xF/AcW4zfwLDMKL 8Ifm1/Nw9wQu3kDa1u/C2HWFSBh+DK2lyQGigWmjNOD/IuIyZnzApUG/9rEwTv/kWFqo cj8A== X-Gm-Message-State: AOJu0Yz+NDNoars2AqhJnB2VWiCowgbVZIVegq4InitEsZSkzZUKKug1 b6+z4Txw5UOt621yrqSQU3+96F8byt3n301qT1/MGforoTT0rqV28QSMncc75kd8UPAcYwyKtoI 2LJ+F3Gk= X-Gm-Gg: AeBDietLaQaejhBioaCRNTgTSPhTUAnIVESXmttXm3rpfvOzX+JtxAo0fN58Fwmuw2R UIwj19KCANmoVtCwpnjABUjG7DRn8xg7jxbyTXt9Q/C5bHVP2Vab22d8fHYV+Tet7tqoqyHFSVH M80DXj/2uMwH6C4SYQMoKNfef+cLu1trODqWi9cDMc1s/FPqHBzO5xZf95tAMMpFWovgK07s05s 8N3nzrxAqYqPMoxFFKn+yiHkL3FPyKXW5MdpxuZxbpmUoNyf+LUCvblUNdZzTIyCMGCKHQ/6r6E w150alXmDMm92rAhE1JR02ZA5qB7SeMjIpGFIAYY+Mt57UyBdigrCiTuRP2yf+lY8CXiFFOCOwl xlPEordf+vPYBg/0Wr0RdW2x0Fewlfzg2MfL15Ff25QMMhCKCC7aNN6qJqWTvzlO5BQXnJn8fyM d0Z/hZgQ4iANupcPBBYXN99UyF+7nDbh0Oxn4v X-Received: by 2002:a05:7300:7f9f:b0:2d4:94cc:eebb with SMTP id 5a478bee46e88-2ed0a0da75fmr3609047eec.13.1777484190139; Wed, 29 Apr 2026 10:36:30 -0700 (PDT) Received: from mozart.vkv.me ([2001:5a8:468b:d015:eadf:43ff:5bad:d931]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2ed1c09c6e3sm2899087eec.25.2026.04.29.10.36.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 10:36:29 -0700 (PDT) From: Calvin Owens To: linux-kernel@vger.kernel.org Cc: linux-perf-users@vger.kernel.org, x86@kernel.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Andi Kleen Subject: [PATCH v2 2/2] perf: Don't throttle based on NMI watchdog events Date: Wed, 29 Apr 2026 10:36:11 -0700 Message-ID: <33d87384aa5f96af76949d1399476779dd4f4fce.1777483573.git.calvin@wbinvd.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The throttling logic in perf_sample_event_took() assumes the NMI is running at the maximum allowed sample rate. While this makes sense most of the time, it wildly overestimates the runtime of the NMI for the perf hardware watchdog: # bpftrace -e 'kprobe:perf_sample_event_took { \ printf("%s: cpu=3D%02d time_taken=3D%dns\n", \ strftime("%H:%M:%S.%f", nsecs), cpu(), arg0); }' 03:12:13.087003: cpu=3D00 time_taken=3D3190ns 03:12:13.486789: cpu=3D01 time_taken=3D2918ns 03:12:18.075288: cpu=3D03 time_taken=3D3308ns 03:12:19.797207: cpu=3D02 time_taken=3D2581ns 03:12:23.110317: cpu=3D00 time_taken=3D2823ns 03:12:23.510308: cpu=3D01 time_taken=3D2943ns 03:12:29.229348: cpu=3D03 time_taken=3D3669ns 03:12:31.656306: cpu=3D02 time_taken=3D3262ns The NMI for the watchdog runs for 2-4us every ten seconds, but the math done in perf_sample_event_took() concludes it is running for 200-400ms every second! When it is the only PMU event running, it can take minutes to hours of samples from the watchdog for the moving average to accumulate to something near the real mean, which causes the same little "litany" of sample rate throttles to happen every time Linux boots with the perf hardware watchdog enabled: perf: interrupt took too long (2526 > 2500), lowering kernel.perf_event= _max_sample_rate to 79000 perf: interrupt took too long (3177 > 3157), lowering kernel.perf_event= _max_sample_rate to 62000 perf: interrupt took too long (3979 > 3971), lowering kernel.perf_event= _max_sample_rate to 50000 perf: interrupt took too long (4983 > 4973), lowering kernel.perf_event= _max_sample_rate to 40000 This serves no purpose: it doesn't actually affect the runtime of the watchdog NMI at all. It confuses users, because it suggests their machine is spinning its wheels in interrupts when it isn't. Because the watchdog NMI is so infrequent, we can avoid throttling it by making the throttling a two-step process: load and update a timestamp whenever we think we need to throttle, and only actually proceed to throttle if the last time that happened was less than one second ago. This is inelegant, but it avoids touching the hot path and preserves current throttling behavior for real PMU use, at the cost of delaying the throttling by a single NMI. Signed-off-by: Calvin Owens --- Changes in v2: * Sashiko spotted that nesting NMIs could cause throttling to be skipped incorrectly. But its suggestions were terrible, ignore them and use __this_cpu_cmpxchg() to solve the problem instead. * Sashiko notes that NMIs which last over one second firing on a period of greater than one second will also skip throttling: I don't believe that could ever actually happen, but this isn't a hot path, so I added a check that the current NMI took less than a second just to be sure. kernel/events/core.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 6d1f8bad7e1c..c2a33cb194ce 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -623,6 +623,7 @@ core_initcall(init_events_core_sysctls); */ #define NR_ACCUMULATED_SAMPLES 128 static DEFINE_PER_CPU(u64, running_sample_length); +static DEFINE_PER_CPU(u64, last_throttle_clock); =20 static u64 __report_avg; static u64 __report_allowed; @@ -643,6 +644,8 @@ void perf_sample_event_took(u64 sample_len_ns) u64 max_len =3D READ_ONCE(perf_sample_allowed_ns); u64 running_len; u64 avg_len; + u64 last; + u64 now; u32 max; =20 if (max_len =3D=3D 0) @@ -663,6 +666,19 @@ void perf_sample_event_took(u64 sample_len_ns) if (avg_len <=3D max_len) return; =20 + /* + * Very infrequent events like the perf counter hard watchdog + * can trigger spurious throttling: skip throttling if the prior + * NMI got here more than one second before this NMI began. But + * never skip throttling if NMIs are nesting, or if any NMI runs + * for longer than one second. + */ + now =3D local_clock(); + last =3D __this_cpu_read(last_throttle_clock); + if (__this_cpu_cmpxchg(last_throttle_clock, last, now) =3D=3D last && + now - last > NSEC_PER_SEC && sample_len_ns < NSEC_PER_SEC) + return; + __report_avg =3D avg_len; __report_allowed =3D max_len; =20 --=20 2.47.3