[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0htK3V2uPvqczirL9WW2Pgip00VP6xd8pqbOKvCUPhSbQ@mail.gmail.com>
Date: Mon, 3 Mar 2025 13:08:32 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Alan Stern <stern@...land.harvard.edu>,
Johan Hovold <johan@...nel.org>, Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Saravana Kannan <saravanak@...gle.com>
Subject: Re: [PATCH v1 0/5] PM: sleep: Improvements of async suspend and
resume of devices
On Mon, Mar 3, 2025 at 1:07 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Tue, 25 Feb 2025 at 17:46, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> >
> > Hi Everyone,
> >
> > Initially, this was an attempt to address the problems described by
> > Saravana related to spawning async work for any async device upfront
> > in the resume path:
> >
> > https://lore.kernel.org/linux-pm/20241114220921.2529905-1-saravanak@google.com/
> >
> > but then I realized that it could be extended to the suspend path and
> > used for speeding it up, which it really does.
> >
> > Overall, the idea is that instead of starting an async work item for every
> > async device upfront, which is not very efficient because the majority of
> > those devices will not be able to make progress due to dependencies anyway,
> > the async handling is only started upfront for the devices that are likely
> > to be able to make progress. That is, devices without parents in the resume
> > path and leaf devices (ie. devices without children or consumers) in the
> > suspend path (the underlying observation here is that devices without parents
> > are likely to have no suppliers too whereas devices without children that
> > have consumers are not unheard of). This allows to reduce the amount of
> > processing that needs to be done to start with.
> >
> > Then, after processing every device ("async" or "sync"), "async" processing
> > is started for some devices that have been "unblocked" by it, which are its
> > children in the resume path or its parent and its suppliers in the suspend
> > path. This allows asynchronous handling to start as soon as it makes sense
> > without delaying the "async" devices unnecessarily.
> >
> > Fortunately, the additional plumbing needed to implement this is not
> > particularly complicated.
>
> Thanks for the detailed description! Overall, the approach makes
> perfect sense to me too!
>
> I am certainly interested to hear Saravana's thoughts around this too.
>
> >
> > The first two patches in the series are preparatory.
>
> For these two, feel free to add:
>
> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
>
> >
> > Patch [3/5] deals with the resume path for all device resume phases.
> >
> > Patch [4/5] optimizes the "suspend" phase which has the most visible effect (on
> > the systems in my office the speedup is in the 100 ms range which is around 20%
> > of the total device resume time).
> >
> > Patch [5/5] extend this to the "suspend late" and "suspend noirq" phases.
>
> I will try to have a closer look at patch 3->5 later in the week.
Thank you and thanks for all of the other reviews!
Powered by blists - more mailing lists