Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1230600imm; Fri, 27 Jul 2018 13:28:23 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdIqxlYCDoCw5wQJdTWEqHNlFrVuG1EK0Ut+pdIYnB5cOwCFt+fergHzQzxmw1zeww1YV96 X-Received: by 2002:a17:902:904c:: with SMTP id w12-v6mr7352583plz.95.1532723303525; Fri, 27 Jul 2018 13:28:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532723303; cv=none; d=google.com; s=arc-20160816; b=NnZO4+b76NgkU4E5brNdvnmFHH1jPLQE6JEJHY3nNq3rbdeXNBCUU8xZrYdj5Vglyd Hb3JoTOKFT1BRTSEyWFgTzDODGmpy1eUIuE9t+IZyGzQTcqw8W212aR+8v1WH7T9+eBi TZDRxhWN9yxGsu4lIqZsa/pKYRq9Te3Hhk4pkTx8BBXy4AmwirBbo4mRdl9IAnE7VLIF ZO95FWopeLsHIFuHc+tuKx29osMF7K7wxVtA5MSTfA0ofuPXFueYyeWtt//VbKEvy+q8 uDuuni1a1qdwyDOdio5JBGSY2u8prMyWaWx11A/ew+IikBvcLG185C5TViZe/sRkj74p ao1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=izdAaZzJtgm0RR9/YMTlEO7b7uL+TkVGCtauaE9cA1Y=; b=ekPUb/JMwOpiVPJy/zJs+yOHuUKmuJod9hLtrYMlzwxNxt/6YX0nrfkrtrJI+n3jLc kczoKbxa/O3AHAWlDtIlrb7PdgP3S2g9JsWWf/FK1xXl3pQBlEo2eVCT4AUC/0m8kwro WYjKLqUzjodK4xzC66PvFB+xqZjV0hWCaaLHLsYITsTV8zfYcGsR76LGjgB0X2WZeshL eM/Om4pBvtDLx3erHeGGldOeWULEzoCMJW5Y35MimULnfopoF+e8/fJZ7FvAUhrRicM+ OLWVC4WvG4EIOQTHB49w3cSaF296LF4+zG90D5eQ5z2DTVbAb0QbvwSR/XBdlqPQFpp2 b5PQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JbiEBUDz; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d1-v6si4168320pld.515.2018.07.27.13.28.08; Fri, 27 Jul 2018 13:28:23 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=JbiEBUDz; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389584AbeG0Vty (ORCPT + 99 others); Fri, 27 Jul 2018 17:49:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:54394 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389210AbeG0Vtx (ORCPT ); Fri, 27 Jul 2018 17:49:53 -0400 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A6A8420671; Fri, 27 Jul 2018 20:26:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1532723182; bh=bs6tU4soZemLTfvgJ80Mz5P3OQJtIk59h6hgSNWdu9M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JbiEBUDz528t6L/JNHS1U60PgRhfJWzi0x6kbpVIsnghsjvA0kkE+NaMMwlhgny5q pmY1zNieX/dpPqpvDugplbMLkJmmqHIAIx8rC4zIgXO78pwrplmiibbt5Jhfy0Y3Fo G8nBskJZXDj4rpygGQoZIMnwwtL9OQn4dPY04B80= Date: Fri, 27 Jul 2018 15:26:19 -0500 From: Bjorn Helgaas To: Rajat Jain Cc: Bjorn Helgaas , Keith Busch , Vidya Sagar , Philippe Ombredanne , Kees Cook , "Gustavo A. R. Silva" , Ard Biesheuvel , Sinan Kaya , Frederick Lawler , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, mayurkumar.patel@intel.com, rajatxjain@gmail.com, Richard Hughes , Carlos Garnacho , "Rafael J. Wysocki" , Pali Rohar , Takashi Iwai , Andy Whitcroft , Colin Ian King Subject: Re: [PATCH v2] pci/aspm: Remove CONFIG_PCIEASPM_DEBUG Message-ID: <20180727202619.GD173328@bhelgaas-glaptop.roam.corp.google.com> References: <20180508230148.121852-1-rajatja@google.com> <20180510233912.96454-1-rajatja@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510233912.96454-1-rajatja@google.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+cc Rafael, Richard, Carlos, Pali, Takashi, Andy, Colin for question about how to expose ASPM power management in sysfs] On Thu, May 10, 2018 at 04:39:12PM -0700, Rajat Jain wrote: > ... > And some suggestions from Bjorn here: > https://www.spinics.net/lists/linux-pci/msg60541.html > > This patch picks up one of the suggestion, to remove the > CONFIG_PCIEASPM_DEBUG and thus make the code always > avilable. This provides control to userspace to control > ASPM on a per slot / device basis using sysfs interface. TL;DR: When CONFIG_PCIEASPM_DEBUG=y, Linux makes ASPM control files visible in sysfs, associated with the upstream end (e.g., Root Port) of a link. Should these files be associated with the downstream end (e.g., NIC, GPU, etc) instead? I think we do need to make ASPM control files visible in sysfs, as this patch does. But I have a question about exactly *how* we want to do this. I had planned to merge this patch for v4.19, but I think I'll postpone it until we figure this out. ASPM is a power management feature of a PCIe link, and it affects the devices on both ends of that link. The upstream end (closest to the CPU) is typically a Root Port, and the downstream end is typically an Endpoint (e.g., a GPU, NIC, or NVMe device). For example, my laptop has these devices: 00:1c.2 Intel Root Port to [bus 04] 04:00.0 Intel 8260 Wireless NIC There's a PCIe link between these two devices, and if both ends support it, ASPM reduces power usage when the NIC is idle. The hardware reduces power usage automatically; the kernel only needs to configure ASPM. ASPM affects performance as well as power, so we have knobs to control the tradeoff. Starting with the big hammers, we currently have: - Kernel build-time setting (CONFIG_PCIEASPM_PERFORMANCE, etc). Requires kernel rebuild and reboot. - "pcie_aspm=X" kernel boot parameter. Can only enable/disable and requires a reboot. - /sys/module/pcie_aspm/parameters/policy file. At any time, root can set the system-wide ASPM policy to one of these settings: + highest performance, highest power consumption + moderate power saving at cost of some performance + aggressive power saving at cost of more performance + use whatever setting BIOS configured - Many /sys/devices/pci0000:00/0000:00:1c.2/power/link_state files. At any time, root can set the ASPM policy to one of the above settings, but for individual devices. Currently these files are only available when CONFIG_PCIEASPM_DEBUG=y (Red Hat does not enable this, but Ubuntu does). The patch below changes it so these /sys/devices/.../link_state files *always* exist, regardless of CONFIG_PCIEASPM_DEBUG. The question is where those sysfs files should be. Currently they are associated with the device at the *upstream* end of the link. In the example above, they're associated with the Root Port: /sys/devices/pci0000:00/0000:00:1c.2/power/link_state I don't know if that's the right place, or if they should be associated with the device at the *downstream* end of the link, i.e., 04:00.0. The downstream end might be better because: - It's easier to associate the downstream end with a device the user cares about, e.g., a NIC, GPU, etc. This is mostly a user- interface issue. - A link can lead to a multi-function device, and the spec allows those functions to have different ASPM settings (see PCIe r4.0, sec 5.4.1). With the sysfs files at the upstream end of the link, we have no way to configure those functions individually. Any thoughts? > ... > diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig > index b12e28b3d8f9..089b9f559d88 100644 > --- a/drivers/pci/pcie/Kconfig > +++ b/drivers/pci/pcie/Kconfig > @@ -46,14 +46,6 @@ config PCIEASPM > > When in doubt, say Y. > > -config PCIEASPM_DEBUG > - bool "Debug PCI Express ASPM" > - depends on PCIEASPM > - default n > - help > - This enables PCI Express ASPM debug support. It will add per-device > - interface to control ASPM. > - > choice > prompt "Default ASPM policy" > default PCIEASPM_DEFAULT > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c > index c687c817b47d..8ffc13d42baa 100644 > --- a/drivers/pci/pcie/aspm.c > +++ b/drivers/pci/pcie/aspm.c > @@ -1161,7 +1161,6 @@ static int pcie_aspm_get_policy(char *buffer, const struct kernel_param *kp) > module_param_call(policy, pcie_aspm_set_policy, pcie_aspm_get_policy, > NULL, 0644); > > -#ifdef CONFIG_PCIEASPM_DEBUG > static ssize_t link_state_show(struct device *dev, > struct device_attribute *attr, > char *buf) > @@ -1264,7 +1263,6 @@ void pcie_aspm_remove_sysfs_dev_files(struct pci_dev *pdev) > sysfs_remove_file_from_group(&pdev->dev.kobj, > &dev_attr_clk_ctl.attr, power_group); > } > -#endif > > static int __init pcie_aspm_disable(char *str) > { > -- > 2.17.0.441.gb46fe60e1d-goog >