[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MN0PR12MB610109F448E3FC8CE71FBA76E2379@MN0PR12MB6101.namprd12.prod.outlook.com>
Date: Mon, 31 Oct 2022 19:39:29 +0000
From: "Limonciello, Mario" <Mario.Limonciello@....com>
To: Sven van Ashbrook <svenva@...omium.org>,
Rajneesh Bhardwaj <irenic.rajneesh@...il.com>,
Hans de Goede <hdegoede@...hat.com>
CC: LKML <linux-kernel@...r.kernel.org>,
"S-k, Shyam-sundar" <Shyam-sundar.S-k@....com>,
"rrangel@...omium.org" <rrangel@...omium.org>,
"platform-driver-x86@...r.kernel.org"
<platform-driver-x86@...r.kernel.org>,
Rajneesh Bhardwaj <rajneesh.bhardwaj@...el.com>,
Rafael J Wysocki <rjw@...ysocki.net>,
Rajat Jain <rajatja@...gle.com>,
David E Box <david.e.box@...el.com>,
Mark Gross <markgross@...nel.org>
Subject: RE: [PATCH v1] platform/x86: intel_pmc_core: promote S0ix failure
warn() to WARN()
[Public]
> -----Original Message-----
> From: Sven van Ashbrook <svenva@...omium.org>
> Sent: Friday, October 28, 2022 23:12
> To: Rajneesh Bhardwaj <irenic.rajneesh@...il.com>; Hans de Goede
> <hdegoede@...hat.com>
> Cc: Limonciello, Mario <Mario.Limonciello@....com>; LKML <linux-
> kernel@...r.kernel.org>; S-k, Shyam-sundar <Shyam-sundar.S-
> k@....com>; rrangel@...omium.org; platform-driver-
> x86@...r.kernel.org; Rajneesh Bhardwaj <rajneesh.bhardwaj@...el.com>;
> Rafael J Wysocki <rjw@...ysocki.net>; Rajat Jain <rajatja@...gle.com>;
> David E Box <david.e.box@...el.com>; Mark Gross <markgross@...nel.org>
> Subject: Re: [PATCH v1] platform/x86: intel_pmc_core: promote S0ix failure
> warn() to WARN()
>
> On Thu, Oct 27, 2022 at 12:02 PM Rajneesh Bhardwaj
> <irenic.rajneesh@...il.com> wrote:
> > I'd advise against this promotion based on my experience with S0ix entry
> failures.
>
> On Thu, Oct 27, 2022 at 11:40 AM Hans de Goede <hdegoede@...hat.com>
> wrote:
> > I'm not a fan of the change you are suggesting here.
>
> Thanks everyone for the feedback. Looks like there is consensus that it's
> not advisable to promote the warning. We will move forward with changes to
> our monitoring infrastructure instead.
Did you see the idea proposed by David Box to introduce some infrastructure in
the kernel for this?
Just thinking about it a little bit more, it could be a lot nicer to have something like:
/sys/power/suspend_stats/last_hw_deepest_state
During the resume process drivers such as amd_pmc and intel_pmc_core could
read the appropriate values for the hardware and call a function that would
populate it with either a "0" or "1" or maybe even the amount of time spent in
that state.
We could then retire the debugging messages from both drivers and instead of
your infrastructure relying upon scanning logs, userspace could read that sysfs
file after every suspend and raise the alarms when it's 0 (or if it's populated with
time smaller than X% of the total suspend time).
Powered by blists - more mailing lists