From: Sinan Kaya <okaya@codeaurora.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: "Raj, Ashok" <ashok.raj@intel.com>,
Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Yinghai Lu <yinghai@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Keith Busch <keith.busch@intel.com>
Subject: Re: [GIT PULL] PCI fixes for v4.10
Date: Tue, 2 May 2017 10:15:27 -0400 [thread overview]
Message-ID: <5db97592-4153-c55a-fe44-260d717d1ef0@codeaurora.org> (raw)
In-Reply-To: <20170502104929.GA14029@wunner.de>
On 5/2/2017 6:49 AM, Lukas Wunner wrote:
> On Mon, May 01, 2017 at 10:41:20PM -0400, Sinan Kaya wrote:
>> On 5/1/2017 9:54 PM, Lukas Wunner wrote:
>>> (b) ASPM L1 enabled on boot, but disabled after powering off and back on
>>> => I believe Sinan is working on this (+cc).
>>
>> The decision was made not to touch ASPM registers following hotplug insertion
>> unless pcie_aspm.policy=powersave is specified.
>>
>> The discussion is here: https://lkml.org/lkml/2017/4/17/255
>>
>> This was done to maintain existing behavior and not break things.
>
> Thanks for the reference, I hadn't followed the discussion in April
> very closely, but I think the outcome of the discussion is unfortunate.
>
> As can be seen in Ashok's tests, merely turning slot power off and back
> on is sufficient to end up with a setting that draws more power. That
> may be equally surprising for users as the issues would be that we seek
> to avoid with a "safety-first" ASPM policy. In any case it seems
> undesirable.
>
> I hope this is not the end if it and would like to encourage you to
> keep working on this. Perhaps it is too simple to just define a
> default policy, and what is really needed is a policy that adjusts
> itself dynamically to specific devices or workloads, or that can be
> influenced by device drivers.
>
I think our conclusion was to push PM decision to a userspace utility.
ASPM already has a knob in sysfs that can be adjusted at runtime. The
name of the file is policy. Same argument as the kernel command line
but it is writable. Different policies can be programmed into this
field after OS boot.
It is really the system power management entity that needs to decide
how system should behave.
We just need to educate the userspace utility about the presence
of ASPM policy variable.
1. OS could still boot with the default parameters.
2. Userspace utility sets the policy variable to powersave
3. User performs hotplug remove + insert
4. ASPM is enabled due to policy change.
I don't know anything about what this userspace utility is or if
it understands about PCIE ASPM at all.
As an analogy, we can choose the level of power management in windows
through Power Policy.
control panel -> power options -> change advanced power options ->
PCI Express -> Link State Power Management
We want to have the same level of configuration.
> Thanks for your efforts,
>
> Lukas
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2017-05-02 14:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170208192054.GA31395@bhelgaas-glaptop.roam.corp.google.com>
2017-02-08 19:22 ` [GIT PULL] PCI fixes for v4.10 Bjorn Helgaas
2017-02-09 4:06 ` Lukas Wunner
2017-02-09 15:09 ` Bjorn Helgaas
2017-02-09 18:23 ` Raj, Ashok
2017-02-09 18:46 ` Raj, Ashok
2017-05-02 1:54 ` Lukas Wunner
2017-05-02 2:41 ` Sinan Kaya
2017-05-02 10:49 ` Lukas Wunner
2017-05-02 14:15 ` Sinan Kaya [this message]
2017-05-02 18:48 ` Bjorn Helgaas
2017-05-03 18:04 ` Raj, Ashok
2017-05-06 9:04 ` Lukas Wunner
2017-02-09 20:11 ` Bjorn Helgaas
2017-02-10 12:39 ` Rafael J. Wysocki
2017-02-11 2:39 ` Yinghai Lu
2017-02-11 7:13 ` Yinghai Lu
2017-02-12 19:05 ` Lukas Wunner
2017-02-13 12:10 ` Rafael J. Wysocki
2017-02-16 14:51 Bjorn Helgaas
-- strict thread matches above, loose matches on Subject: below --
2017-02-02 16:18 Bjorn Helgaas
2017-02-02 16:30 ` Christoph Hellwig
2017-02-02 16:46 ` Bjorn Helgaas
2017-01-19 14:27 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=5db97592-4153-c55a-fe44-260d717d1ef0@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=ashok.raj@intel.com \
--cc=helgaas@kernel.org \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).