All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Rajat Jain <rajatja@google.com>,
	"Patel, Mayurkumar" <mayurkumar.patel@intel.com>,
	Rajat Jain <rajatxjain@gmail.com>,
	David Daney <david.daney@cavium.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Timur Tabi <timur@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Julia Lawall <Julia.Lawall@lip6.fr>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Myron Stowe <myron.stowe@redhat.com>
Subject: Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init
Date: Mon, 17 Apr 2017 11:38:21 -0500	[thread overview]
Message-ID: <CAErSpo7p_2dTDTC7J4HdQUw_5GH8081dUZ=XVqd=sRLrA_FJnA@mail.gmail.com> (raw)
In-Reply-To: <66168dde-7719-6f74-3f06-8e4724dd2918@codeaurora.org>

On Fri, Apr 14, 2017 at 5:17 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 4/14/2017 5:44 PM, Bjorn Helgaas wrote:
>> I think there's an argument to be made that if we care about ASPM
>> configuration, we should be using a non-POLICY_DEFAULT setting.  And I
>> think there's value in having POLICY_DEFAULT be the absolute lowest-
>> risk setting, which I think means option 1.
>>
>> What do you think?
>
> I see your point. The counter argument is that most of the users do not
> know what an ASPM kernel command line is unless they understand PCI
> language.

I don't think the answer is using the "pcie_aspm.policy=" boot
argument.  I certainly don't want users to have to deal with that.  I
wish we didn't even have that parameter.

I think we need runtime knobs instead (and I guess we already have
/sys/module/pcie_aspm/parameters/policy and /sys/.../link_state), and
distro userspace should use them.  I'm envisioning something in
"System Settings / Power" or similar.  Basically I think the policy
doesn't *have* to be dictated by a kernel boot-time parameter, so it
should not be.

> I have been using the powersave policy option until now. I recently realized
> that nobody except me is using this option. Therefore, we are wasting
> power by default following a hotplug insertion.
>
> This is the case where I'm trying to avoid. With the introduction of NVMe
> u.2 drives, hotplug is becoming more and more mainstream. I decided to
> take the matters into my hand with this series for this very reason.
>
> Like you said, BIOS is out of the picture with pciehp. There is nobody
> to configure ASPM following a hotplug insertion.
>
> I can also claim that If user wants performance, they should boot with
> the performance policy or pcie_aspm=off parameters.
>
> I saw this recommendation in multiple DPDK tuning documents.
>
> Like you said, what do we do by default is the question. Should we opt
> for safe like we are doing, or try to save some power.

I think safety is paramount.  Every user should be able to boot safely
without any kernel parameters.  We don't want users to have a problem
booting and then have to search for a workaround like booting with
"pcie_aspm=off".  Most users will never do that.

Here's a long-term strawman proposal, see what you think:

  - Deprecate CONFIG_PCIEASPM_DEFAULT, CONFIG_PCIEASPM_POWERSAVE, etc.
  - Default aspm_policy is POLICY_DEFAULT always.
  - POLICY_DEFAULT means Linux doesn't touch anything: if BIOS enabled
ASPM, we leave it that way; we leave ASPM disabled on hot-added
devices.
  - Deprecate kernel boot parameters (possibly keep pcie_aspm=off for
debugging use).
  - Use /sys/module/pcie_aspm/parameters/policy for run-time
system-wide  control, including for future hot-added devices.
  - Remove CONFIG_PCIEASPM_DEBUG and enable that code always, so we
have fine-grained run-time control.

> Maybe, we are missing a HPP option from the PCI spec.

That's an interesting idea.  _HPX does have provision for manipulating
Link Control bits (see ACPI r5.0, sec 6.2.8.3), but I don't think very
many systems implement it.  And there's currently no connection
between program_hpp_type2() and aspm.c, so I'm a little worried that
we might have issues if a system did implement an _HPX that sets any
of the ASPM bits.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: bhelgaas@google.com (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init
Date: Mon, 17 Apr 2017 11:38:21 -0500	[thread overview]
Message-ID: <CAErSpo7p_2dTDTC7J4HdQUw_5GH8081dUZ=XVqd=sRLrA_FJnA@mail.gmail.com> (raw)
In-Reply-To: <66168dde-7719-6f74-3f06-8e4724dd2918@codeaurora.org>

On Fri, Apr 14, 2017 at 5:17 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 4/14/2017 5:44 PM, Bjorn Helgaas wrote:
>> I think there's an argument to be made that if we care about ASPM
>> configuration, we should be using a non-POLICY_DEFAULT setting.  And I
>> think there's value in having POLICY_DEFAULT be the absolute lowest-
>> risk setting, which I think means option 1.
>>
>> What do you think?
>
> I see your point. The counter argument is that most of the users do not
> know what an ASPM kernel command line is unless they understand PCI
> language.

I don't think the answer is using the "pcie_aspm.policy=" boot
argument.  I certainly don't want users to have to deal with that.  I
wish we didn't even have that parameter.

I think we need runtime knobs instead (and I guess we already have
/sys/module/pcie_aspm/parameters/policy and /sys/.../link_state), and
distro userspace should use them.  I'm envisioning something in
"System Settings / Power" or similar.  Basically I think the policy
doesn't *have* to be dictated by a kernel boot-time parameter, so it
should not be.

> I have been using the powersave policy option until now. I recently realized
> that nobody except me is using this option. Therefore, we are wasting
> power by default following a hotplug insertion.
>
> This is the case where I'm trying to avoid. With the introduction of NVMe
> u.2 drives, hotplug is becoming more and more mainstream. I decided to
> take the matters into my hand with this series for this very reason.
>
> Like you said, BIOS is out of the picture with pciehp. There is nobody
> to configure ASPM following a hotplug insertion.
>
> I can also claim that If user wants performance, they should boot with
> the performance policy or pcie_aspm=off parameters.
>
> I saw this recommendation in multiple DPDK tuning documents.
>
> Like you said, what do we do by default is the question. Should we opt
> for safe like we are doing, or try to save some power.

I think safety is paramount.  Every user should be able to boot safely
without any kernel parameters.  We don't want users to have a problem
booting and then have to search for a workaround like booting with
"pcie_aspm=off".  Most users will never do that.

Here's a long-term strawman proposal, see what you think:

  - Deprecate CONFIG_PCIEASPM_DEFAULT, CONFIG_PCIEASPM_POWERSAVE, etc.
  - Default aspm_policy is POLICY_DEFAULT always.
  - POLICY_DEFAULT means Linux doesn't touch anything: if BIOS enabled
ASPM, we leave it that way; we leave ASPM disabled on hot-added
devices.
  - Deprecate kernel boot parameters (possibly keep pcie_aspm=off for
debugging use).
  - Use /sys/module/pcie_aspm/parameters/policy for run-time
system-wide  control, including for future hot-added devices.
  - Remove CONFIG_PCIEASPM_DEBUG and enable that code always, so we
have fine-grained run-time control.

> Maybe, we are missing a HPP option from the PCI spec.

That's an interesting idea.  _HPX does have provision for manipulating
Link Control bits (see ACPI r5.0, sec 6.2.8.3), but I don't think very
many systems implement it.  And there's currently no connection
between program_hpp_type2() and aspm.c, so I'm a little worried that
we might have issues if a system did implement an _HPX that sets any
of the ASPM bits.

Bjorn

  reply	other threads:[~2017-04-17 16:38 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-08  4:55 [PATCH V8 0/5] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT Sinan Kaya
2017-04-08  4:55 ` Sinan Kaya
2017-04-08  4:55 ` Sinan Kaya
2017-04-08  4:55 ` [PATCH V8 1/5] PCI/ASPM: introduce pci_aspm_init() and add to pci_init_capabilities() Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-13 20:51   ` Bjorn Helgaas
2017-04-13 20:51     ` Bjorn Helgaas
2017-04-14 19:10     ` Sinan Kaya
2017-04-14 19:10       ` Sinan Kaya
2017-04-08  4:55 ` [PATCH V8 2/5] PCI/ASPM: split pci_aspm_init() into two Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-12 19:16   ` Rajat Jain
2017-04-12 19:16     ` Rajat Jain
2017-04-13 18:25     ` Bjorn Helgaas
2017-04-13 18:25       ` Bjorn Helgaas
2017-04-13 18:25       ` Bjorn Helgaas
2017-04-14 19:10       ` Sinan Kaya
2017-04-14 19:10         ` Sinan Kaya
2017-04-14 19:10         ` Sinan Kaya
2017-04-08  4:55 ` [PATCH V8 3/5] PCI/ASPM: add init hook to device_add Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-13 20:48   ` Bjorn Helgaas
2017-04-13 20:48     ` Bjorn Helgaas
2017-04-13 20:48     ` Bjorn Helgaas
2017-04-13 21:02     ` Bjorn Helgaas
2017-04-13 21:02       ` Bjorn Helgaas
2017-04-13 21:02       ` Bjorn Helgaas
2017-04-14  1:19       ` Sinan Kaya
2017-04-14  1:19         ` Sinan Kaya
2017-04-14  1:30         ` Bjorn Helgaas
2017-04-14  1:30           ` Bjorn Helgaas
2017-04-08  4:55 ` [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-12 19:19   ` Rajat Jain
2017-04-12 19:19     ` Rajat Jain
2017-04-12 19:19     ` Rajat Jain
2017-04-14 19:12     ` Sinan Kaya
2017-04-14 19:12       ` Sinan Kaya
2017-04-14 19:12       ` Sinan Kaya
2017-04-14 21:44       ` Bjorn Helgaas
2017-04-14 21:44         ` Bjorn Helgaas
2017-04-14 21:44         ` Bjorn Helgaas
2017-04-14 22:17         ` Sinan Kaya
2017-04-14 22:17           ` Sinan Kaya
2017-04-17 16:38           ` Bjorn Helgaas [this message]
2017-04-17 16:38             ` Bjorn Helgaas
2017-04-17 17:50             ` Sinan Kaya
2017-04-17 17:50               ` Sinan Kaya
2017-04-21  7:46               ` Patel, Mayurkumar
2017-04-21  7:46                 ` Patel, Mayurkumar
2017-04-21  7:46                 ` Patel, Mayurkumar
2017-04-21  7:46                 ` Patel, Mayurkumar
2017-04-21 13:50                 ` Sinan Kaya
2017-04-21 13:50                   ` Sinan Kaya
2017-04-21 14:13                   ` Patel, Mayurkumar
2017-04-21 14:13                     ` Patel, Mayurkumar
2017-04-21 14:13                     ` Patel, Mayurkumar
2017-04-21 14:13                     ` Patel, Mayurkumar
2017-04-25 18:45                 ` Bjorn Helgaas
2017-04-25 18:45                   ` Bjorn Helgaas
2017-05-02 12:02                   ` Patel, Mayurkumar
2017-05-02 12:02                     ` Patel, Mayurkumar
2017-05-02 12:02                     ` Patel, Mayurkumar
2017-05-03 21:10                     ` Bjorn Helgaas
2017-05-03 21:10                       ` Bjorn Helgaas
2017-05-03 21:10                       ` Bjorn Helgaas
2017-05-15  9:10                       ` Patel, Mayurkumar
2017-05-15  9:10                         ` Patel, Mayurkumar
2017-05-15  9:10                         ` Patel, Mayurkumar
2017-05-15  9:10                         ` Patel, Mayurkumar
2017-04-08  4:55 ` [PATCH V8 5/5] PCI/ASPM: move link_state cleanup to bridge remove Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-08  4:55   ` Sinan Kaya
2017-04-10 11:37 ` [PATCH V8 0/5] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT Patel, Mayurkumar
2017-04-10 11:37   ` Patel, Mayurkumar
2017-04-10 11:37   ` Patel, Mayurkumar
2017-04-10 13:07   ` Sinan Kaya
2017-04-10 13:07     ` Sinan Kaya
2017-04-10 13:07     ` Sinan Kaya
2017-04-10 13:11     ` Patel, Mayurkumar
2017-04-10 13:11       ` Patel, Mayurkumar
2017-04-10 13:11       ` Patel, Mayurkumar
2017-04-11 21:19 ` Bjorn Helgaas
2017-04-11 21:19   ` Bjorn Helgaas
2017-04-11 21:19   ` Bjorn Helgaas
2017-04-11 21:27   ` Sinan Kaya
2017-04-11 21:27     ` Sinan Kaya
2017-04-11 22:41     ` Bjorn Helgaas
2017-04-11 22:41       ` Bjorn Helgaas
2017-04-11 22:41       ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAErSpo7p_2dTDTC7J4HdQUw_5GH8081dUZ=XVqd=sRLrA_FJnA@mail.gmail.com' \
    --to=bhelgaas@google.com \
    --cc=Julia.Lawall@lip6.fr \
    --cc=david.daney@cavium.com \
    --cc=helgaas@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mayurkumar.patel@intel.com \
    --cc=myron.stowe@redhat.com \
    --cc=okaya@codeaurora.org \
    --cc=rajatja@google.com \
    --cc=rajatxjain@gmail.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=timur@codeaurora.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.