From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (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 DA0843290D0 for ; Wed, 29 Jul 2026 13:04:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785330296; cv=none; b=fi6Ncr4+6oRioVZOt14Zu9gDNi7qHyF8MQi5qePmC2m31VhF9KPOkVElCRqDWDjWQjr+EqRsGd0a+45eiXpJ2rSWio/iTF2ur4vSFGxcz/eEWs7AyEdj0XWR0hMC7L++bXv8d1rpKMPi4wFBelrohCNzRy73r4lLFB7jkoO6ui0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785330296; c=relaxed/simple; bh=M/b4Qb28AC6fSlZDuFNcWIa9ejQ9hr6k/ZCYkV64hyI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OxMr3A/NkrqAE0RLzopT2xmvbld135aObSiyamJDk3Y7RF7XBuFE0lrqHL6DsMlcbP9v43gQX0s3fQ9p+dsnyihTcXO+u67HwBf8HYp7ObdKNkDeXatKSQbJtB2wZE+hFKQGpK+/cQgGH98pyXGRsuhsrihtq17hN+XfebRx7NE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CRov5rN0; arc=none smtp.client-ip=209.85.215.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CRov5rN0" Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-caf707e3a70so1479573a12.1 for ; Wed, 29 Jul 2026 06:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785330294; x=1785935094; 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:content-type; bh=M/b4Qb28AC6fSlZDuFNcWIa9ejQ9hr6k/ZCYkV64hyI=; b=CRov5rN0yVt0WXnv/T4hISU7U24FT6VjE+1X6xY5zp2TEozhw2icGJF7/lFSrkQcxf MA0Vfdl+MoSGJHvJc4B5P31GXXsp+BzoM8Wzyq7YU7TMLWmTNwBYsP2WX244yelnH0eo 1fgTRoPbBkUDi9VULZrseSntd3RlvtQs/Z3kDRxjlrdCyYrVKnnIEDJVFVW3c2IKgI96 WSZ45rXDmnCOAD4rroQvkqvW+hacyjpsBm4c00AimobVQ9ur/z8KjZweuQu0c4abT6zQ eoR+VnR60znP+0oILCx5VHQvHLrT/NJ8QYs4Qg15ZX6d2bYP0UJgS646r0Icc7a4nCoG EXGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785330294; x=1785935094; 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:content-type; bh=M/b4Qb28AC6fSlZDuFNcWIa9ejQ9hr6k/ZCYkV64hyI=; b=pvj86k4Q1PNyd0s92QXxVnplubZbP2trPBEs6L5faM+x5AlfTZ/TlrPK/0yER3TsU6 +2jl7x84yYpa1NYwbvVudIYUW2EdAV1lCxQE1ipkOVSZ9A99A0Jw5CAd31cgeFEd/SwS aFmKvtzRdUL3YuDYFSR0bGh4FQ9G/02xod4QglJSYRXytLayBYGK04NhT8pzV5PfoC1W eBoWRdqPH/C7YOJYNbdUmlNAduYZn5DYS0a2+RN0qcSaiuB01dhYNCqzu2kq8d3OqQwg 9qWQTwSYq5jK7BFYmhHW5CxHSMjPFk9G/bDEyeIUqPuW4JxG98bNU4P0esHXUlab70V8 YRMw== X-Forwarded-Encrypted: i=1; AHgh+RohymRoSgcn5iZALy/8dFsA6kKz477RbNreLj21nFB8qEfEYuBmnpPsSo4/8a3QGAZqdqYr1iWQNX/lv40=@vger.kernel.org X-Gm-Message-State: AOJu0Ywgext8lrxSdT3LDLqgJDDyli8HKdif4K+dwH8UIDlgSe3f/yaD /Y+j3D+DMudk/YkYs5mfOYLwwF4aVYbOqjzg8YjPk8ImcYud3DoBRL6Q X-Gm-Gg: AR+sD12YIlFpvo9yOFtje8IKkhhNYKD4NBkx/kyFp5QnIyZCcrwuMXNnwdYiH55zUls PPb82A9PEiC/AubUI4mSELOqf/5WMpp4Wk7dY0X7cgymsUJx8WrXU2njgq5NUudOkzZ2W/EAo4B a+cM7nhmiCHu9xrWxJZDL5PmL9uF2twrDdOlnJgwUjHlvBH/oRbdBZmfQ620XS+++kVOnATfgGy 4/HxlrvcgfNJuhFRT5Rddz3b3IN0/b4XrfJitqW6dMRFKfJ/+58mo7puk8okeRhpaTKr6jVYEhe un+Kcg6M8quRBo/yIWj6nM/MJJuzNLjBzkcn/AP/l2Nzq1dgoj4YNrS/R2HOqqnSbwuI64d8TVZ tKFUR1+KCgTsDwDdb+zJLRgO5roHmEPJrGBXSkFjbt4qzGXZ3talxoBmZI7ZSbAzF7xCICv8P2h 2FykZYxRyHu/Etar2VviNLHKNKRmBnJ821fkOs+AchQpMA X-Received: by 2002:a05:6a21:339f:b0:3c3:7195:fd47 with SMTP id adf61e73a8af0-3c8e47c15fdmr2498419637.24.1785330294098; Wed, 29 Jul 2026 06:04:54 -0700 (PDT) Received: from ubuntu.. ([2a09:bac5:624f:2da5::48c:10]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31504e1ff81sm10330769eec.31.2026.07.29.06.04.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 06:04:53 -0700 (PDT) From: Jing Wu To: Peter Zijlstra Cc: Jing Wu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , "Paul E. McKenney" , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Qiliang Yuan , Jian Zhang , Frederic Weisbecker Subject: Re: [PATCH] x86/aperfmperf: Refresh stale sample via IPI for busy NOHZ_FULL CPUs Date: Wed, 29 Jul 2026 21:04:44 +0800 Message-ID: <20260729130445.2939054-1-realwujing@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260729123912.GZ751831@noisy.programming.kicks-ass.net> References: <20260728-bug-isolatecpu-cpufreq-v1-1-e95d34db8bcd@gmail.com> <20260728134434.GU751831@noisy.programming.kicks-ass.net> <20260728144224.GH651302@noisy.programming.kicks-ass.net> <20260729082225.1675233-1-realwujing@gmail.com> <20260729123912.GZ751831@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, Jul 29, 2026 at 08:39:12PM +0800, Peter Zijlstra wrote: > Oh, you care about the silly sysfs files? I though this was about the > scheduler use of aperf/mperf ratio. > > Both are driven from the same source, but the scheduler use makes no > sense when isolated/NOHZ_FULL. And I would argue that keeping the CPU > isolated is more important than having the silly number 'accurate'. Yes, sorry for the confusion - it's the sysfs files. To be concrete about why: when someone is chasing a real incident (packet latency in an OVS/DPDK PMD pipeline pinned to one of these cores, say), reading scaling_cur_freq/cpuinfo is one of the first things they check. Seeing the P-state floor while the core is genuinely at full turbo sends that investigation down the wrong path and burns real engineering time. -EOPNOTSUPP doesn't fix that particular problem: the operator still gets nothing useful from the standard interface and has to fall back to turbostat regardless, so the diagnostic workflow ends up no better off than it is today. Given that, I'd like to make the case for going back to something closer to the original approach: it's a small, self-contained change, and it reports the actual value instead of an estimate or nothing. The concern was IPIs turning periodic if something scrapes this file on a schedule - but for the isolated cores we run PMD workloads on, nothing polls per-core scaling_cur_freq/cpuinfo on any kind of schedule; it only gets read by a person during an investigation, which is a rare, deliberate action, not unlike running turbostat by hand. Would you reconsider on that basis, or is there a middle ground you'd be open to?