From mboxrd@z Thu Jan 1 00:00:00 1970 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 8E9C4381AE7 for ; Wed, 29 Apr 2026 17:36:27 +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=1777484190; cv=none; b=d2P+Hk8cqOZ1QxwR0LxLbdfcvOq7neltIrOyG3r7Ffcxw/OnyqbODXD2weuIcIvP8dFC9mVT/TnYnJmMLNbfqeAVCE0zL55nEI6ze2TUrR5HGXy9/SIeD77IMnpFZe/xA8bWCANNqMQdRFpwbddxidgxJN6zZNeuioRweygJpOc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777484190; c=relaxed/simple; bh=rbsBVPTHVp24qvxU2IVJVxWmUYIL1gdsUjJFJuBiVks=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NiD/RzCcVxeCjTCguJGr8XaoFtRuBOXEDfebAhu3h34j1Tn7RWFZuPDYKLUagratcGxxfdZmA3ObKSggmj5OmGseuwnz2WcdAcotb6/N8chG7bHCH1wlx0fddYt5YnCJMLrFZGY/IIVZ30N4GIr6oVoRdC0xrDcHjmYhUYNarzA= 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=bMjw4+6M; 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="bMjw4+6M" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-2de831d2b20so137035eec.1 for ; Wed, 29 Apr 2026 10:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wbinvd.org; s=wbinvd; t=1777484187; x=1778088987; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=l8cx787r0/c1DcR0zTQ9mKZp9CswPwIysu4DNnG68zM=; b=bMjw4+6MOZjCCHAfBSgbozR70YjvMWlFIu3WckGb8yNn07XkY0aBnW27TJRia6ekvg yYS3I6nwXEscfhUNmCyBOVaIBe4Ky681zlLz/d/pBuZJSoz3/K0sXWLzomqQNcWkv7St ODAebS687VwVcetxOMsCo5Ue4SoyzfAazM95nSknKOKAu0R6UlRka9CDwWRJJxUN/uLz LTz18p8fPedFA6Xi+8rIP4r+WiRtbtt7l+nf4dMOiwNcvcqLjTxC/oy8F29HsYWLdaNg TtklzBGMAhOJqrB/rVJLWgfe/cABpF8llBKrPztzxSt5ygOcsld8XyE4RQBcLe1PNgEK 0jKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777484187; x=1778088987; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=l8cx787r0/c1DcR0zTQ9mKZp9CswPwIysu4DNnG68zM=; b=rUaICxAX6NjOcah1zfdoDvk63jU0ICjHZbREde62zWHGWa40U9A0b0TJwtdbdXM9qh D2jSqLckei1mukfautVZ7K9UWxWpQe/8vFKfIAnRsPK+CGiHPuv/scfkp02bAKzKqZqw Fimsq9IfOyImIn/WaS7jX1Cpy9f+zbRKe3r+ZITUuspXjBhWF+/LlDekJIelUS/tygje k0YTAQ05pL1KNixZdYtSGfaKL3M6GgsrB5SSw0657TU/eerqXySXSzufKhGsP9oOUoQT 7erJshX/Y7F6dvkx2S5KaJDDjT/vERqVD3clC6Fc5qe8Hr1KuYtbUJ7k5eUq9R2MCfTk pHqQ== X-Gm-Message-State: AOJu0Yz5Cb3bKt5Di7W+cOaV2BuhJoJArv4ykAXiCxQ2yyrs0htn73PP BrqFEe3QlnWiHtYlY810VYrTurmSwMV439saXszhZ0sqZq7tfFKoHR4GRPMwn1AAktvFbIfgQud bAcnbZy4= X-Gm-Gg: AeBDiev0ZcNlbSZWEB2vUb2GhPa3GWCXbfHqWHdpQJHGhWXTxTcu3ezDJ9SEgf0mZo4 1O6L+PcDv5jd1dgL2/kxcSfcVAqbuRejprwUrbIUQOInBmqDPKV8NyRcI8s7r0cNtrgt1V3CNg4 Zhaw8Urz5R48J19n4c0dhLEYxvpTNu07NQYqiNqpPvaMHa6jLZZcdPzvSldtOAXQRS7gQ/YjvSi djXJA54xdIxYfuiMZ8XJXC0wgJxPRkNqzyggch0bX8PN8NFQq1HLaYYqlZZtQxE6zPDBF3FMc9/ foPeKecKZp0KDWGFaKD5SN8bsPnWFZUq55ILG5Lhm+6vXUzHdq63uJ3ChIgoXokfEuIvdWm0gnG ZJnt7P1ZCfoWhA9MGh2nHEcttje3W9lYdcbXPSVUfI3oxBwRD4A+PFG61D/uJk6mV6B85dmG5je w8OfMoRPfcxN+wfuzBFfhqqaCaabw7OosZi1TIQf6ZsKU/rsQ= X-Received: by 2002:a05:7300:8628:b0:2e6:e7da:7c30 with SMTP id 5a478bee46e88-2ed0a0f1139mr4447996eec.17.1777484186634; Wed, 29 Apr 2026 10:36:26 -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.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2026 10:36:26 -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 0/2] Two semi-related perf throttling fixes Date: Wed, 29 Apr 2026 10:36:09 -0700 Message-ID: X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi all, This is a refresh of this little series: https://lore.kernel.org/lkml/cover.1774969692.git.calvin@wbinvd.org/ Patch [1/2] is the same, patch [2/2] has two minor fixes described in the patch itself. The remainder of this cover is the same as in v1. Cheers, Calvin --- In the course of investigating [1], I set out to understand why this sequence of messages is printed every boot, even when nobody is using perf at all: perf: interrupt took too long (2516 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 perf: interrupt took too long (3156 > 3145), lowering kernel.perf_event_max_sample_rate to 63000 perf: interrupt took too long (4014 > 3945), lowering kernel.perf_event_max_sample_rate to 49000 perf: interrupt took too long (5035 > 5017), lowering kernel.perf_event_max_sample_rate to 39000 perf: interrupt took too long (6302 > 6293), lowering kernel.perf_event_max_sample_rate to 31000 perf: interrupt took too long (7879 > 7877), lowering kernel.perf_event_max_sample_rate to 25000 perf: interrupt took too long (9852 > 9848), lowering kernel.perf_event_max_sample_rate to 20000 It turns out this happens because of how the dynamic sample rate throttling interacts with the perf hardware watchdog. Patch [2/2] is my attempt to prevent the dynamic throttling logic from acting solely based on the latency of the watchdog NMI. Intel CPUs were happy with that. But AMD CPUs still printed the messages! That happens because AMD CPUs have a second PMU facility with its own NMI handler, and both NMI handlers average in their latency, even when they don't actually handle the NMI. Patch [1/2] fixes that, which is a correctness issue entirely independent of patch [2/2]. But it also happens to be required for patch [2/2] to achieve its goal on AMD CPUs, so I sent them together. Thanks, Calvin [1] https://lore.kernel.org/all/acMe-QZUel-bBYUh@mozart.vkv.me/ Calvin Owens (2): perf/x86: Avoid double accounting of PMU NMI latencies perf: Don't throttle based on NMI watchdog events arch/x86/events/amd/ibs.c | 6 +++--- arch/x86/events/core.c | 3 ++- kernel/events/core.c | 16 ++++++++++++++++ 3 files changed, 21 insertions(+), 4 deletions(-) -- 2.47.3