From patchwork Fri Apr 15 19:19:48 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 563817 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B37D0C433EF for ; Fri, 15 Apr 2022 19:19:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348220AbiDOTWW (ORCPT ); Fri, 15 Apr 2022 15:22:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347427AbiDOTWV (ORCPT ); Fri, 15 Apr 2022 15:22:21 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A3CC3EA8B; Fri, 15 Apr 2022 12:19:52 -0700 (PDT) Message-ID: <20220415133356.179706384@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1650050389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=PCqHGYWha2qFzocY7lkicGkVazPbVuiY2oKAGLDRIdk=; b=id6wN8fokQD9vuyR0yBA6iQJVE56ax9xur7Pj1ITWMwyOhb3j/OecRzufFIpQ+M9W79q4l 2fVezPQ7mvnNXZoz9bCTj6VxGc27EChT0GchKIacgkQU8+Kq/ns8acQOQqATpRw/13aYyS qDDfkESlUvgHazGMr5JzXC2CMD9yTboFbWemELApAMnAHOk53Yz2LAuBB5r/QZMMXO0SL7 eok3QIq8BP8lQa3AgAsKAfsNwict5EU46XJbeEGeoT/17/ArHQEbuUUjTN2qoSNUfo1s0p 1qW+W/vSuUz+gLBsH+DIM/HaLobz8wY+hKHlC81IBXxNtaj+W/11x5HOHHu2bg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1650050389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=PCqHGYWha2qFzocY7lkicGkVazPbVuiY2oKAGLDRIdk=; b=D8rExBpcz27gnAebY69pf4uuu9Bo00GVd+WX/9/WyJ4bqlPi08HPrdqsXeU5S68gV1zxp1 NhQwgotnoI4tneCw== From: Thomas Gleixner To: LKML Cc: x86@kernel.org, "Rafael J. Wysocki" , linux-pm@vger.kernel.org, Eric Dumazet , "Paul E. McKenney" Subject: [patch 00/10] x86/cpu: Consolidate APERF/MPERF code MIME-Version: 1.0 Date: Fri, 15 Apr 2022 21:19:48 +0200 (CEST) Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org APERF/MPERF is utilized in two ways: 1) Ad hoc readout of CPU frequency which requires IPIs 2) Frequency scale calculation for frequency invariant scheduling which reads APERF/MPERF on every tick. These are completely independent code parts. Eric observed long latencies when reading /proc/cpuinfo which reads out CPU frequency via #1 and proposed to replace the per CPU single IPI with a broadcast IPI. While this makes the latency smaller, it is not necessary at all because #2 samples APERF/MPERF periodically, except on idle or isolated NOHZ full CPUs which are excluded from IPI already. It could be argued that not all APERF/MPERF capable systems have the required BIOS information to enable frequency invariance support, but in practice most of them do. So the APERF/MPERF sampling can be made unconditional and just the frequency scale calculation for the scheduler excluded. The following series consolidates that. Thanks, tglx Acked-by: Paul E. McKenney Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/cpu.h | 2 arch/x86/include/asm/topology.h | 17 - arch/x86/kernel/acpi/cppc.c | 28 -- arch/x86/kernel/cpu/aperfmperf.c | 474 +++++++++++++++++++++++++++++++-------- arch/x86/kernel/cpu/proc.c | 2 arch/x86/kernel/smpboot.c | 358 ----------------------------- fs/proc/cpuinfo.c | 6 include/linux/cpufreq.h | 1 8 files changed, 405 insertions(+), 483 deletions(-)