Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <cb5ab68e-5034-d937-e28e-e838e50172a8@amd.com>
Date:   Mon, 31 Oct 2022 20:58:27 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH v1] platform/x86: intel_pmc_core: promote S0ix failure
 warn() to WARN()
Content-Language: en-US
To:     Sven van Ashbrook <svenva@chromium.org>
Cc:     Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>,
        Hans de Goede <hdegoede@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "S-k, Shyam-sundar" <Shyam-sundar.S-k@amd.com>,
        "rrangel@chromium.org" <rrangel@chromium.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>,
        Rafael J Wysocki <rjw@rjwysocki.net>,
        Rajat Jain <rajatja@google.com>,
        David E Box <david.e.box@intel.com>,
        Mark Gross <markgross@kernel.org>
References: <20221027151908.v1.1.I295e65357f06f162b46ea6fc6c03be37e3978bdc@changeid>
 <4b7304c0-8dd5-9add-7c84-4e9f0aa9396b@redhat.com>
 <MN0PR12MB6101BCCA364437A76FED924AE2339@MN0PR12MB6101.namprd12.prod.outlook.com>
 <CAG-rBijvNoN3ppz6bdkEUofYPPBxCtFfo1nWBK5TdG69fcKMnA@mail.gmail.com>
 <CAE2upjS6qRGRcuVYuAB5DMf66A7VcfCKKYEkpsr1My7RnKDFtQ@mail.gmail.com>
 <CAG-rBihDRq1y61tAp56yYCoTOSZXO9OZNzn7gXb_y8XaiO_zqg@mail.gmail.com>
 <MN0PR12MB610109F448E3FC8CE71FBA76E2379@MN0PR12MB6101.namprd12.prod.outlook.com>
 <CAG-rBijSASfbfWQNarjGqj2UxQDOSdwM-qj5YA5A9ur=DNJf-g@mail.gmail.com>
From:   Mario Limonciello <mario.limonciello@amd.com>
In-Reply-To: <CAG-rBijSASfbfWQNarjGqj2UxQDOSdwM-qj5YA5A9ur=DNJf-g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cDg0TFRTL3RxOXJack4yb09oL2sxYjJPT3ZoOVIrNHVGdEpPK2p6SkVhQStt?=
 =?utf-8?B?YWdyTDV6a0txNU1XWk9XckxOZDEzWXpHblExNDZmZnhQOWRGK0FIN2ZMVUR2?=
 =?utf-8?B?NFF6cHhoRWc4dnM5Wnh4dm4xN0JobThPVXZ5ZnpqbmFwM3NLSzZIRE44VzRH?=
 =?utf-8?B?MmROdm9aWCtjcXZPemw5b1IvZUF5bGVZSFFoQ1dBbytwNytUOGJ6MXJ3Y3ZQ?=
 =?utf-8?B?TUEweTlSRUJxRmlUTVJUcWlGOFA4YmhLS1Z5ODR1M0lPQ3IweHNUNGZJUlRi?=
 =?utf-8?B?ZlYzbUtINE16NTl4TlhDRHZ2dGpJODUwaUE1bVZhTUlXOTJZRnBkNFVvSEJq?=
 =?utf-8?B?dmhrTWo4QXcvbkJvZlp2UTVZV3BidmdVaWFCQnVILys4SFZHQXpFVVUzVTRj?=
 =?utf-8?B?bUNRNVJCUWNBc1hGL3dQZXZqaDRqMWQ4SEErb29LRTc3UEp2YmwySVlSMUdl?=
 =?utf-8?B?TkhvaHhrcktIVVcrajdDZ2c0NTF5dVNiNThGT2I3U01HZmJVRkJLR2pmSWlT?=
 =?utf-8?B?Q3F6TG1GNHU1cDlUK0lFSXpaRzVLV3pOM2FTUkUybXBnemdQYmJ1WlluRnpI?=
 =?utf-8?B?azVzTnhvZzh6N2t5MmdWY3A2REZFS1JncGtqZUZzU0QwclVUMTF6dyszS2VT?=
 =?utf-8?B?ZDhhNW90cmxqTXZERm9TNFk5SE9KUEJRbkVxMDdIWGNsRVU0Qi8ybzlWUVlF?=
 =?utf-8?B?aXBtTFhpa3hyWVkzMDZHazlQZXNQV1ArMnFRUzlDSXoySklwT2F1aHF4OUNG?=
 =?utf-8?B?RnRtRnpTaTdrRndKRlFGR3BnWlJxSFJQeUVzaHg0UjlMUndRNlhNWWRlMWZq?=
 =?utf-8?B?NExJUTNIanlTVHFnSldUSWJwSmd1TnR5NDNzMFNQM3hUZGROaG9lL0h2blJ2?=
 =?utf-8?B?Ky9FQm9qZHpVb0VBT3VYR1B0d3pTbUcrY3RPYmxkeGxXSC9neFMvU2NsZ0FQ?=
 =?utf-8?B?d2NwcklPNCs0N2gxNXQxR0txamY4UVFVRm93WHR0UzlPaHJ0b2JETU90bkZ2?=
 =?utf-8?B?Q1g2akRjUEFXYTRPcmUwSDZJNFZZc0NLa2lSRlRhazhkdGR2Z2ZkK25IcHI5?=
 =?utf-8?B?VWl6azh1VTVoLzVwODFWMWJQL1VkaDNwemRiSzJiZlVMWjcvRG1TVWFZbnY0?=
 =?utf-8?B?cHB5M1d2WkQxRTJRNmhXRzlaUnR4NzZrTnBDTmduQXJvTUg3b2RMNXJsTGNE?=
 =?utf-8?B?cUliZk42dmxOekZFdGVvU3YwRytxQnJqbW9uM20zS2xCTm9Fd0E1SUFSVUtr?=
 =?utf-8?B?amFVSnMvMDNLVzBJZkZpcGJHQXNCUXlFQS84WmxtdmY1cEZ0a1FPRXJ0akUx?=
 =?utf-8?B?WXF5M2JoaGJ1Tld5bFp0MjQ2NWVSUWUyaHVlNjRlMUFiT2FJOFlTeVFQZm1V?=
 =?utf-8?B?ZWc4a1VWT1Rpb2c0T01XckcxYlkydW03VWZjV2MySi9nLzMxUGdxT2pzTDF3?=
 =?utf-8?B?VU5YWERzRjVESEZOVVRMMGZVT1RPaXhiMkkrWnNxSnIvbFhIbHl4bzN6WjZO?=
 =?utf-8?B?WnJvWnZhaDZQU281S1JOcjQ3M1ROK2YrUkczS0xGNytTZW9BazVPQ0ZiaUow?=
 =?utf-8?B?ZmcvRTB1MkVQVHlDVTZuRGVBd2FLQ1VONE5KNGVNeGRCamdYemM3a0dIZWZ1?=
 =?utf-8?B?MVNOeDZ6bTIzQ3Z5SWQyY2JhaEp5UVN4MDRVcDIrc2FtanRmVVlUQ3c4aWxI?=
 =?utf-8?B?ODhqMlZxMTlKLzFybHpsMjJiVVptazArNW9TL0o5STc1YkVnYlE3d1g0cThC?=
 =?utf-8?B?bENsY2dPZDdmKzBuaDN0VkFkL29KUXZPL3l2ekF2SEpxdDZCbmpKalFPZ1or?=
 =?utf-8?B?MGlhZ01xSHAxQXFkY1Yvdzk1NFVmNjdZNGpSNVVnNW1aRDRkdHh1YnhGdTBL?=
 =?utf-8?B?dHhiUGFSU2M3NTlGMnJaNGFvWnpEMmswYU1nUnM5djdNTkY5OXpRblNOT2Rh?=
 =?utf-8?B?VW5IQjdRekI5RzNaeFdNa29qaG0xRUhZSEVzMElVT3ZJeHo4MGRuM0ZsWFpN?=
 =?utf-8?B?MkVmTFRVaDh6N3pSaVB5dldmbG5ucGcwYjBIVFF1WkVEVEhyWU5WeWtOaTI2?=
 =?utf-8?B?c0o5RStGdlVCVWtNcXE5elZ2WWpFdUd5QXZKWUhBWDNYZGM2WUtjY3hmeUsv?=
 =?utf-8?B?TFZrU2F4M3g3M1dtcUlhQlVleXBDVGR4YUpBU1JzMy9EaEhWL0U5ZDFXa2hr?=
 =?utf-8?Q?OjmEOaCb8P2ACT3JIU1ycwv1Zj74c45g/bVEln6wWzZs?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 941d4a2a-f9dc-4d61-3ea0-08dabbac937a
X-MS-Exchange-CrossTenant-AuthSource: MN0PR12MB6101.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2022 01:58:31.0471
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 2QugXSU+Mn1BhdbH30+hMoCp56mCR5N4o9PlPB5dwak/igdnH9Ng4clFpMA0fya6mfTZy848ZuazDpwrslvjmA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5819
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/31/22 20:38, Sven van Ashbrook wrote:
> On Mon, Oct 31, 2022 at 3:39 PM Limonciello, Mario
> <Mario.Limonciello@amd.com> wrote:
>>
>> 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
> 
> While I agree that reporting through a framework is generally better
> than getting infrastructure to grep for specific strings, I believe
> that a simple sysfs file is probably too simplistic.
> 
> 1. We need more sophisticated reporting than just last_hw_deepest_state:
> 
> - sometimes the system enters the deep state we want, yet after a
> while moves back up and gets "stuck" in an intermediate state (below
> S0). Or, the system enters the deep state we want, but moves back to
> S0 after a time without apparent reason. These platform-dependent
> failures are not so easily describable in a generic framework.

I actually thought that by putting the duration of time put in 
last_hw_deepest_state you'll be able to catch this by comparing the 
duration of the suspend to the duration of last_hw_deepest_state.

If you're below some threshold of percent for suspends that are at least 
some other threshold long you can trigger the failure.

This then lets you tune your framework to find the right place for those
thresholds too without needing to change the kernel.

> 
> - ChromeOS in particular has multiple independent S0ix / S3 / s2idle
> failure report sources. We have the kernel warning above; also our
> Embedded Controller monitors suspend failure cases which the simple
> kernel warning cannot catch, reported through a separate WARN_ONCE().
>  > 2. A simple sysfs file will need to be polled by the infrastructure
> after every suspend; it would be preferable to have some signal or
> callback which the infrastructure could register itself with.

The interface to trigger a suspend is writing a value into 
/sys/power/state.  You'll get a return code from this, but this return 
code does not represent whether you got to the deepest state, just 
whether the suspend succeeded or not.

So what would an ideal interface that sends a signal that the last 
"successful" suspend didn't get to the deepest state look like to you?

> 
> The generic infrastructure to support this sounds like quite a bit of
> work, and for what gain? Compared to simply matching a log string and
> sending the whole dmesg if there's a match.

I would like to think it's cheaper to read the sysfs file, do a local 
comparison on HW deepest time to the suspend time and then only send the 
the dmesg up for further analysis.

> 
> Is the light worth the candle?

I wrote an RFC that I sent out for it with my ideas at least.