From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC6F4C433B4 for ; Fri, 14 May 2021 16:15:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A4CAF613F1 for ; Fri, 14 May 2021 16:15:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229654AbhENQQl (ORCPT ); Fri, 14 May 2021 12:16:41 -0400 Received: from mga03.intel.com ([134.134.136.65]:2787 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229958AbhENQQh (ORCPT ); Fri, 14 May 2021 12:16:37 -0400 IronPort-SDR: IJk3ZruCV0V0uc1vYLWUYk5gJEEafW7d3hvftSfRS27kV0iCaVTUizcrzQvk1kUjkDdvFh1nFd e2PHhAL/6Y8w== X-IronPort-AV: E=McAfee;i="6200,9189,9984"; a="200252019" X-IronPort-AV: E=Sophos;i="5.82,300,1613462400"; d="scan'208";a="200252019" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2021 09:15:21 -0700 IronPort-SDR: blY05JkgxFSpOK1YA3Jre2JoSqapjRVMGxhBT9GCrZB4eYzkGHVjIfyPdgjdBGrVXlCUy6tm2Y iS1bWJa/TFMg== X-IronPort-AV: E=Sophos;i="5.82,300,1613462400"; d="scan'208";a="438074788" Received: from rvarsha1-mobl1.gar.corp.intel.com ([10.215.180.45]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2021 09:15:18 -0700 Message-ID: <76e9c2ae095184930669856e9f1a886d92b83f36.camel@linux.intel.com> Subject: Re: [RFC] cpufreq: Excessive CPUFreq driver loading From: Srinivas Pandruvada To: "Meyer, Kyle" , LKML Cc: "rjw@rjwysocki.net" , "viresh.kumar@linaro.org" , "lenb@kernel.org" Date: Fri, 14 May 2021 09:15:14 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2021-05-14 at 14:06 +0000, Meyer, Kyle wrote: > Adding maintainers to the CC list. > > Thank you, > Kyle Meyer > > ________________________________________ > From: Meyer, Kyle > Sent: Thursday, May 6, 2021 9:25 AM > To: LKML > Subject: [RFC] cpufreq: Excessive CPUFreq driver loading > > Hello, > > acpi-cpufreq is mutually exclusive with intel_pstate, however, acpi- > cpufreq is > loaded multiple times during startup while intel_pstate is enabled. > > This issue was reported to the systemd maintainers and they indicated > that it > should be fixed in the kernel: > https://github.com/systemd/systemd/issues/19439 > > During startup, the kernel triggers one uevent for each device as a > result of > systemd-udev-trigger.service executing "udevadm trigger -- > type=subsystems > --action=add" and "udevadm trigger --type=devices --action=add". The > service > exists to retrigger all devices as uevents sent by the kernel, before > systemd-udevd is running, would have been missed. When systemd-udevd > receives a > uevent it matches its configured rules against the device. If a > uevent's > ACTION=="add", systemd-udevd will run "kmod load $env{MODALIAS}" from > 80-drivers.rules. udev's builtin kmod will then attempt to load > modules > matching the device's MODALIAS. > > When systemd-udevd recieves an "add" uevent from > /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:XXX it runs "kmod load > cpu:type:x86, > ...,00E8,..." as "cpu:type:x86,...,00E8,..." is that devices > MODALIAS. > > When systemd-udevd recieves an "add" uevent from > /devices/system/cpu/cpuXXX it > runs "kmod load acpi:ACPI0007:" as "acpi:ACPI0007:" is that devices > MODALIAS. > > acpi-cpufreq is loaded as it matches both devices MODALIASes. > # modinfo acpi-cpufreq | grep alias > alias:          acpi > alias:          cpu:type:x86,ven*fam*mod*:feature:*00E8* > alias:          cpu:type:x86,ven*fam*mod*:feature:*0016* > alias:          acpi*:ACPI0007:* > alias:          acpi*:LNXCPU:* > > On a system with 1536 logical CPUs, systemd-udevd attempts to load > acpi-cpufreq > 3072 times. > > 1536 * /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:XXX > 1536 * /devices/system/cpu/cpuXXX > > The delay, caused by systemd-udevd attempting to load the driver, has > a > significant impact on the startup time. It causes some devices to be > unavailable after reaching the root login prompt as it postpones the > loading of > other drivers. > > Each time that the driver is loaded it returns -EEXIST from > acpi_cpufreq_init. > static int __init acpi_cpufreq_init(void) > { >         int ret; > >         if (acpi_disabled) >                 return -ENODEV; > >         /* don't keep reloading if cpufreq_driver exists */ >         if (cpufreq_get_current_driver()) >                 return -EEXIST; > ... > > Changing the return value from -EEXIST to 0 when another driver > exists prevents > the driver from being loaded multiple times as kmod won't load a > "live" module. > Alternatively, blacklisting the driver (or disabling intel_pstate) > prevents the > issue as well. Below are the before and after startup times. > > # systemd-analyze > Startup finished in 37.939s (kernel) + 10.909s (initrd) + 3min > 55.004s (userspace) = 4min 43.852s > > # systemd-analyze > Startup finished in 38.307s (kernel) + 10.205s (initrd) + 38.312s > (userspace) = 1min 26.826s That is a big difference. i think when you return 0, lsmod will show the module loaded. But that shouldn't be a problem in my opinion. Thanks, Srinivas > > Thank you, > Kyle Meyer