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]
Date:	Fri, 8 May 2015 10:34:13 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Len Brown <lenb@...nel.org>
cc:	rjw@...ysocki.net, <linux-pm@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()

On Fri, 8 May 2015, Len Brown wrote:

> From: Len Brown <len.brown@...el.com>
> 
> Remove sys_sync() from the kernel's suspend flow.
> 
> sys_sync() is extremely expensive in some configurations,
> and so the kernel should not force users to pay this cost
> on every suspend.
> 
> The user-space utilities s2ram and s2disk choose to invoke sync() today.
> A user can invoke suspend directly via /sys/power/state to skip that cost.

I can understand the motivation for this, but is it aimed in the right 
direction?

Consider a system where sys_sync() is very expensive.  Should such a
system be using system suspend in the first place?  If there is a valid
use case, why does the extra overhead of sys_sync() matter?

To put it another way, if the system wants to go into a low-latency
suspend state, why doesn't it use an extreme version of runtime suspend
rather than system suspend?

This reminds me of the discussions we had with the Android developers
when they proposed adding wakelocks to the kernel -- they needed them
so that they could support system suspend when what they really wanted
to do was an extreme version of runtime suspend.  But generally
speaking, sys_sync() is not tremendously expensive on devices running
Android.

Alan Stern

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ