linux-kernel - Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

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: <55AE66FC.6060509@gmail.com>
Date:	Tue, 21 Jul 2015 11:36:28 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rafael@...nel.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"Brown, Len" <len.brown@...el.com>, Len Brown <lenb@...nel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional

On 2015-07-21 11:19, Pavel Machek wrote:
> On Tue 2015-07-21 16:41:12, Rafael J. Wysocki wrote:
>> Hi Pavel,
>>
>> On Tue, Jul 21, 2015 at 11:38 AM, Pavel Machek <pavel@....cz> wrote:
>>> On Sat 2015-07-18 01:54:09, Rafael J. Wysocki wrote:
>>>> On Wednesday, July 15, 2015 02:58:22 PM Brown, Len wrote:
>>
>> [cut]
>>
>>>>>>> Why do you need CONFIG parameter?
>>>>>
>>>>> So that an OS that doesn't want to change their user-space,
>>>>> can build a kernel that does what they want by default.
>>>>>
>>>>> Originally I had the config parameter remove this code entirely,
>>>>> which would achieve the same goal.
>>>>> But Rafael prefers the sysfs attribute always exist
>>>>> and the config simply set the default.
>>>>
>>>> Indeed.
>>>>
>>>> And so I'm queuing this patch up for 4.3 (with a couple of minor fixups).
>>>
>>> Please don't.
>>>
>>> "OS that doesn't want to change the user-space to speed up suspend by
>>> few milliseconds" is not a valid reason for asking about million users
>>> one more config question.
>>
>> That's your opinion and I beg to differ.
>
> Perhaps explaining your opinion would help here? Having to echo value
> to file to improve performance over reliability does not look too
> burdensome on the users.
>
>>> Affected users can't run mainline kernel
>>> anyway, and will have to change their userland in non-trivial ways to
>>> get there.
>>
>> And I'm not sure what you're talking about here.  Who are the
>> "affected users" in particular?
>
> Who does enter suspend to ram multiple times a second? Only android,
> AFAICT. Can you run android on mainline kernel? No. Can you run
> android on kernel with less that 100k lines of patches? No.
>
> So who benefits from the new config option? No one.
You mean aside from the fact that calling sync multiple times during the 
suspend path is wasteful and (potentially) puts unnecessary stress on 
the hardware.  All userspace that I know of calls sync() at least once 
(and sometimes twice) before telling the kernel to enter suspend.  I 
will accede that for some people, having sys_sync() get called by the 
kernel during suspend is useful (for example, I don't use any special 
userspace software for STR on my laptop, because it works fine without 
it, I just 'echo mem > /sys/power/state').

Also, I'd be willing to bet that FirefoxOS, and whatever Amazon is using 
on their tablets and phones also suspend multiple times a second, and 
some ChromeOS systems might in the near future as well (and ChromeOS is 
pretty darn close to being able to run on mainline).

I would personally say this should be default y and presenting it as a 
choice should require CONFIG_EXPERT to be y.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)