Date: Tue, 2 Jul 2024 15:20:05 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Chang, Kaiyen" <kaiyen.chang@...el.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, "pavel@....cz" <pavel@....cz>, "Brown, Len" <len.brown@...el.com>, 
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, 
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Todd Brandt <todd.e.brandt@...ux.intel.com>
Subject: Re: [PATCH v2 1/1] PM: Start asynchronous suspend threads upfront

On Thu, Jun 20, 2024 at 11:21 AM Chang, Kaiyen <kaiyen.chang@...el.com> wrote:
>
> On Tue, Jun 18, 2024 at 07:27:18PM +0200, Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Tue, Jun 18, 2024 at 2:13 PM Kaiyen Chang <kaiyen.chang@...el.com>
> > wrote:
> > >
> > > Currently, when performing a suspend operation, all devices on the
> > > dpm_list must wait for the "synchronous" devices that are listed after
> > > them to complete before the main suspend thread can start their
> > > suspend routines, even if they are "asynchronous". If the suspend
> > > routine of a synchronous device must enter a waiting state for some
> > > reason, it will cause the main suspend thread to go to sleep, thereby
> > > delaying the processing of all subsequent devices, including
> > > asynchronous ones, ultimately extending the overall suspend time.
> > >
> > > By starting the asynchronous suspend threads upfront, we can allow the
> > > system to handle the suspend routines of these asynchronous devices in
> > > parallel, without waiting for the suspend routines of the synchronous
> > > devices listed after them to complete, and without breaking their
> > > order with respect to their parents and children.
> > > This way, even if the main suspend thread is blocked, these
> > > asynchronous suspend threads can continue to run without being
> > > affected.
> > >
> > > Signed-off-by: Kaiyen Chang <kaiyen.chang@...el.com>
> >
> > How exactly has this been tested?
> >
> > In the past, changes going in this direction caused system suspend to hang on
> > at least some platforms (including the ones in my office).
> >
>
> Hi Rafael, thanks for your reply.
>
> 1. We have currently verified this patch on the ADL-N Chromebook, running the suspend stress test 1000 times consecutively without encountering any issues.

Just one machine?  That's hardly sufficient.

> 2. Could you tell us what was the reason for suspend to hang back then?

It was what is still the case I think: Some dependencies between
devices are implicitly taken into account when the async suspend
threads are not started upfront.

> The reason why I believe that we can start the async device's suspend threads
> upfront is that, during resume, a sync devices listed after certain async devices
> on the list do not actually rely on the implicit dependency provided by the order
> of the devices on the list.

This problem has nothing to do with resume, because the machines hang
during suspend.

> This is because if there is no consumer-supplier or parent-children relationship between
> these devices, the suspend routine of this sync device will be executed directly without
> waiting for the suspend routines of the async devices listed before it to complete. In other
> words, this sync device does not depend on the async devices listed before them.

Well, not quite, IIUC.

Say there are two devices, A and B, the former is "sync" and the
latter is "async".  Say there is a dependency between them such that A
must suspend before B, but it is not expressed directly (no
parent-child relationship and no device link).

If A is before B in the list order and async suspend is not started
upfront, the dependency is met.  If async suspend is started upfront,
B may suspend before A.

> Therefore, during suspend, there is no need to ensure those async devices listed
> before the sync devices are awake before these sync devices complete their suspend
> routines. In summary, as long as we manage the dependencies between
> consumers/suppliers and parents/children relationships properly, we should be
> able to start the async devices' suspend routines upfront during suspend.

Well, if the dependencies are all represented either through
parent-child relationships or through device links, then yes, but are
they?  On all systems currently in the field?

So if you want to move this forward, please talk to Todd Brandt (CCed)
to arrange for testing your patch in the client power lab.  It must at
least not break suspend on any machines in there.

Powered by blists - more mailing lists