linux-kernel - Re: [PATCH V2 0/4] introduce device async actions mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1249356937.2670.335.camel@rzhang-dt>
Date:	Tue, 04 Aug 2009 11:35:37 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pm <linux-pm@...ts.linux-foundation.org>,
	linux-acpi <linux-acpi@...r.kernel.org>,
	Pavel Machek <pavel@....cz>, Len Brown <lenb@...nel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"dtor@...l.ru" <dtor@...l.ru>
Subject: Re: [PATCH V2 0/4] introduce device async actions mechanism

On Tue, 2009-08-04 at 05:18 +0800, Rafael J. Wysocki wrote:
> On Friday 24 July 2009, Zhang Rui wrote:
> > Hi,
> 
> Hi,
> 
> > this is the patch set I made to speed up the device
> > suspend/resume/shutdown process.
> > 
> > A new mechanism called Device Async Actions is introduced
> > in this patch set.
> 
> Well, I'm not sure we'll need that.
> 
> > The basic idea is that,
> > if the suspend/resume/shutdown process of a device group, including
> > a root device and its child devices, are independent of other devices,
> > we create an async domain for this device group,
> > and make them suspend/resume/shutdown asynchronously.    
> 
> I don't really think this is the right approach.  IMO, we should rather try to
> identify groups of devices for which the PM callbacks (forget about .shutdown()
> for now) can be executed in parallel.

hah, I see.
You want to execute as more PM callbacks at one time as possible,
right?
I'm afraid this won't bring as many benefits as it looks like because
most of the suspend/resume time is cost on several specified devices.

Take the dmesg I attached for example.

total device suspend time is 1.532s.
serio2		0.407s
sd 0.0.0.0	0.452s
serio0		0.103s
0b.4.2		0.114s
00.1f.2		0.080s
00.19.0		0.072s
all the others	0.304s

total device resume time is 2.899s
PNP0C0A:00(bat)	0.896s
00.19.0		0.056s
0b.4.0		0.139s
0b.1.1		0.064s
usb1		0.052s
usb2		0.051s
usb3		0.042s
usb8		0.248s
sd 0.0.0.0	0.118s
usb 3-1		0.261s
usb 8-1		0.511s
all the others	0.461s

We can see that these several devices take 80%~85% suspend/resume time,
while all the other (nearly 500) devices take 20%.

Running a lot device PM callbacks at one time is not equal to saving a
lot time if the devices listed above still run synchronously.

So I think the key point to speed up suspend/resume is to invoke the PM
callbacks of these devices asynchronously.
And I use the asynchronous functions for two reasons.
1. devices with dependency are in the same asynchronous domain so that
   their PM callbacks run in-order.
2. PM callbacks of the devices without any dependency run
asynchronously
   by using different asynchronous domains.

> One such group is leaf devices, ie.
> devices that have no children.  Of course, some of them will depend of the
> other indirectly, so we should make it possible to declare (in the driver)
> whether the device can be suspended/resumed asynchronously and use the
> following logic (at the core level), in pseudo code:
> 
> if (has_no_children(dev) && asynchronous_suspend_resume_allowed(dev))
>     async_resume(dev);
> else
>     resume(dev);
> 
> and analogously for suspend.  Then, we can easily use one async domain for all
> of these devices.

> Later, we can add async domains for devices that have children, but can be
> suspended and woken up in parallel with each other.
>   IOW, I think the async
> domains should span the levels rather than branches of the device
> tree.
> 

Hmm, as I said above,
this approach works only if we can make sure that the specified devices
are put in the same async domain, i.e. run in parallel.
are there any prototype patches available?

thanks,
rui

View attachment "dmesg-synchronously" of type "text/plain" (120886 bytes)

View attachment "lspci" of type "text/plain" (2291 bytes)