[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190423154920.uytvswrxx7plv3dh@wunner.de>
Date: Tue, 23 Apr 2019 17:49:20 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: Alex G <mr.nuke.me@...il.com>, bhelgaas@...gle.com,
helgaas@...nel.org, linux-pci@...r.kernel.org,
austin_bolen@...l.com, alex_gagniuc@...lteam.com,
keith.busch@...el.com, Shyam_Iyer@...l.com, okaya@...nel.org,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI/LINK: Account for BW notification in vector
calculation
On Tue, Apr 23, 2019 at 09:34:08AM -0600, Alex Williamson wrote:
> On Tue, 23 Apr 2019 09:33:53 -0500 Alex G <mr.nuke.me@...il.com> wrote:
> > 0.5W savings on a 100+W GPU? I agree it's meaningless.
>
> Evidence? Regardless, I don't have control of the driver that's making
> these changes, but the claim seems unfounded and irrelevant.
On laptops, 0.5 W can result in noticeably longer battery life.
> I can see why we might want to
> be notified of degraded links due to signal issues, but what I'm
> reporting is that there are also entirely normal and benign reasons
> that a link might be reduced, we can't seem to tell the difference
> between a fault and this normal dynamic scaling, and the assumption of
> a fault is spamming dmesg. So, I don't think what we have here is well
> cooked. Do drivers have a mechanism to opt-out of this error
> reporting?
Is dmesg spammed even if no driver is bound to a GPU? If so, that would
suggest a solution that's not dependent on drivers. E.g., the
bw_notification port service could avoid reports for devices matching
PCI_BASE_CLASS_DISPLAY. (It could also avoid binding to ports whose
children include such a device, but the child may be hot-pluggable
and thus appear only after the port is bound.) Then we'd still get
a notification on boot about degraded link speed, but not continuous
messages.
Thanks,
Lukas
Powered by blists - more mailing lists