linux-kernel - Re: [PATCH 0/2] Run callback of device

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2994160.MkjLhsn0bK@vostro.rjw.lan>
Date:	Sat, 08 Jun 2013 03:52:30 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	yanmin_zhang@...ux.intel.com
Cc:	Greg KH <gregkh@...uxfoundation.org>, shuox.liu@...el.com,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	pavel@....cz, len.brown@...el.com
Subject: Re: [PATCH 0/2] Run callback of device_prepare/complete consistently

On Saturday, June 08, 2013 09:36:03 AM Yanmin Zhang wrote:
> On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
> > On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> > > On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > > > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > > > On Friday, June 07, 2013 04:20:30 PM shuox.liu@...el.com wrote:
> > > > > > dpm_run_callback is used in other stages of power states changing.
> > > > > > It provides debug info message and time measurement when call these
> > > > > > callback. We also want to benefit ->prepare and ->complete.
> > > > > > 
> > > > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> > > > > 
> > > > > Is this an "Oh, why don't we do that?" series, or is it useful for anything
> > > > > in practice?  I'm asking, because we haven't added that stuff to start with
> > > > > since we didn't see why it would be useful to anyone.
> > > > > 
> > > > > And while patch [1/2] reduces the code size (by 1 line), so I can see some
> > > > > (tiny) benefit from applying it, patch [2/2] adds more code and is there any
> > > > > paractical reason?
> > > > Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> > > > or wakeup slowly) and we need optimize it.
> > > > With the 2 patches, we could collect initcall_debug printk info and manually
> > > > check what prepare/complete callbacks consume too much time.
> > > 
> > > But initcall information is for initialization stuff, not suspend/resume
> > > things, right?  Doesn't the existing tools for parsing this choke if it
> > > sees the information at suspend/resume time?
> > 
> > We've been using that for suspend/resume for quite some time too, but not
> > for the prepare/complete phases (because we still believe that's not really
> > useful for them). 
> > 
> > Well, I'll be handling patches changing code under drivers/base/power,
> > I promise. :-)
> > 
> > I've been doing that for quite a few years now ...
> Yes, indeed. Power is one of the most important features on embedded devices.
> Lots of smart phones don't really go through the full cycles of suspend-to-ram.
> We are following the full steps of the suspend.

But if you go through the code, you'll see that alomost no drivers actually
implemet .prepare() and .complete().  Some subsystems do, but they really don't
take too much time to execute.  Which means that your patches with
initcall_debug will add quite a pile of useless garbage to the kernel log and
I'm not sure how that helps?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/