Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp6493332ybx; Mon, 11 Nov 2019 10:01:29 -0800 (PST) X-Google-Smtp-Source: APXvYqz5jBxwGtlobnQti+nE/hqFfKlQZ5X1wL+b3TaHG0PAT55V+mkVS+TRtc0NoU6+aIiLrbkE X-Received: by 2002:aa7:d552:: with SMTP id u18mr28016454edr.86.1573495288899; Mon, 11 Nov 2019 10:01:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573495288; cv=none; d=google.com; s=arc-20160816; b=Ib52yMZigsXMDvcCNDWu80KtonR6vfmqV6VXwAPyUOpO9KLRfwmwcHP+kt8TyoYsti 2Jtt9QccZ/F0dBjs2EfTgU7EYTPb0V99zTfQ82Wnzl4MltdhIhRJgsamraEz5EV0GUHE FS71sHSozxpJHNGd028CmT0weNrVxsh5Or83yTYit0Sxo8lbKMaXpPLUafhFMsi5eu7f jeulDxczm/cuumNIzHxW68yzpCY/+WUU9Cz9xrjdih0ryLmaL00mNQYEbdnMNZJwWw9J EBGg1bV02XO2oiZmR7w7YxXWzmqleJEuMlLLQBZl4Rk+JaZ6Ju4bm2AFnyg3ii4PWJ6e Ds/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=3PW3u6wLiOwnqst7Zkl0UOcrddXBYP/VT12dQapqK/o=; b=aLbUQckmAySpRslV0KuVaL4CdZ8hxtKR7eCkktWMUMWxXOvFDPU6sWDOJezBsfb38X TARBzgBKhADVxHvOQekISgasHoF00Il99y5yAsZF207XbtF4dMSXWgYWG1pxN9XLOg6C AleaRAUqYyQqEJpECtt2JVwQAlg4bZdIVJl3QNg6JXUwPqntxVkOutmWtbe7eNXiHgzD dTw1tGnnm3+DRUDadSpIK8y0PpEwZpNOPyHlGbhabc7t7lvNU0GRRAkMeuBGrW2ZIbgO 3lVNVdluE6/iSimJszdjGfH8gBe4NLqCXMJKClnLnkfozOzaIZLwoy1iuuXRgkhNSu5J CpTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4si9730746ejx.132.2019.11.11.10.01.03; Mon, 11 Nov 2019 10:01:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726964AbfKKSAY (ORCPT + 99 others); Mon, 11 Nov 2019 13:00:24 -0500 Received: from mx2.suse.de ([195.135.220.15]:33684 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726741AbfKKSAY (ORCPT ); Mon, 11 Nov 2019 13:00:24 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4F721B2E9; Mon, 11 Nov 2019 18:00:21 +0000 (UTC) From: Giovanni Gherdovich To: Srinivas Pandruvada , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Borislav Petkov , Len Brown , "Rafael J . Wysocki" Cc: x86@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Mel Gorman , Matt Fleming , Viresh Kumar , Juri Lelli , Paul Turner , Vincent Guittot , Quentin Perret , Dietmar Eggemann , Doug Smythies , Giovanni Gherdovich Subject: [PATCH 0/6] Add support for frequency invariance for (some) x86 Date: Mon, 11 Nov 2019 19:05:43 +0100 Message-Id: <20191111180549.12166-1-ggherdovich@suse.cz> X-Mailer: git-send-email 2.16.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org v2 at https://lore.kernel.org/lkml/20191002122926.385-1-ggherdovich@suse.cz/ Changes wrt v2: - Removing the tick_disable mechanism. Frequency scale-invariance isn't just about helping schedutil choose better frequencies, but also providing the scheduler load balancer with better metrics. All users of PELT signals benefit from this feature. The tick_disable patch disabled frequency invariant calculation when a specific driver is in use (intel_pstate in active mode). - static_branch_enable(&arch_scale_freq_key) is now called earlier, right after we learn that X86_FEATURE_APERFMPERF is available. Previously Peter Z. commented "if we can't tell the max_freq we don't want to use the invariant stuff.". I've decided to do it differently: if we can't tell the max_freq, then it's because the CPU encodes max_freq in MSRs in a way this patch doesn't understand, and we assume max_p is the max_freq which seems like a safe bet. As a reminder, max_freq=max_p is encoded by setting arch_max_freq=1024 as default value. I'm open to feedback. - Refactoring the switch case statement in set_cpu_max_freq() as Rafael W. Now the first patch doesn't hint at what the following patch will bring along. - Handling the case were turbo is disabled at runtime and a _PPC ACPI notification is issued, as requested by Rafael W. This happens eg. when some laptop model is disconnected from AC. (Patch #6) - Handling all Intel x86_64 micro-arches. - A note for Srinivas P., who expressed concern for Atoms: on Atom CPUs the max_freq is set to the highest turbo level, as a power-efficiency oriented measure. In this way the ratio curr_freq/max_freq tends to be lower, PELT signals are consequently lower, and schedutil doesn't push too hard on speed. (Patches #4 and #5). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cover Letter from v2: v1 at https://lore.kernel.org/lkml/20190909024216.5942-1-ggherdovich@suse.cz/ Changes wrt v1: - add x86-specific implementation of arch_scale_freq_invariant() using a static key that checks for the availability of APERF and MPERF - refer to GOLDMONT_D instead of GOLDMONT_X, according to recent rename - set arch_cpu_freq to 1024 from x86_arch_scale_freq_tick_disable() to prevent PELT from being fed stale data - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cover Letter from v1: This is a resend with of Peter Zijlstra's patch to support frequency scale-invariance on x86 from May 2018 [see 1]. I've added some modifications and included performance test results. If Peter doesn't mind, I'm slapping my name on it :) The changes from Peter's original implementation are: 1) normalizing against the 4-cores turbo level instead or 1-core turbo 2) removing the run-time search for when the above value isn't found in the various Intel MSRs -- the base frequency value is taken in that case. The section "4. KNOWN LIMITATIONS" in the first patch commit message addresses the reason why this approach was dropped back in 2018, and explains that the performance gains outweight that issue. The second patch from Srinivas is taken verbatim from the May 2018 submission as it still applies. I apologies for the length of patch #1 commit message; I've made a table of contents with summaries of each section that should make easier to skim through the content. This submission incorporates the feedback and requests for additional tests received during the presentation made at OSPM 2019 in Pisa three months ago. [1] https://lore.kernel.org/lkml/20180516044911.28797-2-srinivas.pandruvada@linux.intel.com/ Giovanni Gherdovich (6): x86,sched: Add support for frequency invariance x86,sched: Add support for frequency invariance on SKYLAKE_X x86,sched: Add support for frequency invariance on XEON_PHI_KNL/KNM x86,sched: Add support for frequency invariance on ATOM_GOLDMONT* x86,sched: Add support for frequency invariance on ATOM x86: intel_pstate: handle runtime turbo disablement/enablement in freq. invariance arch/x86/include/asm/topology.h | 25 ++++ arch/x86/kernel/smpboot.c | 324 +++++++++++++++++++++++++++++++++++++++- drivers/cpufreq/intel_pstate.c | 1 + kernel/sched/core.c | 1 + kernel/sched/sched.h | 7 + 5 files changed, 357 insertions(+), 1 deletion(-) -- 2.16.4