linux-kernel - Re: [PATCH 1/1] suspend: delete sys

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: <CAJvTdK=ok=xWR16R-3_+kpxujBSFOLqQ3DNNyFgE-Kc8en=PTg@mail.gmail.com>
Date:	Fri, 8 May 2015 12:36:02 -0400
From:	Len Brown <lenb@...nel.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	"linux-kernel@...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, May 8, 2015 at 10:34 AM, Alan Stern <stern@...land.harvard.edu> wrote:
> 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?

There are four significant issues with sys_sync() here:

1. It is not determinitic
    Some devices (and their caches) are quick  on the 1st sync,
    and then slow on the 2nd sync etc.

2. worst case latency is obscene, there are examples of some
    syncs which take over 3,000 ms to complete.

3. It doesn't necessarily deliver on the assumed benefits.
    Rafael tells me that it depends on the file system
    exactly what sync does.  Look no further than the fact
    that for two sync's in a row, the 2nd one may be slower.

4. Whether to sync or not is a policy choice, and that choice
    should be made by the user, not the kernel.  Many systems today
    want to wake for a packet, process that packet, and get back
    to sleep as fast as possible.  Jamming a sys_sync() in their
    wake doesn't make sense.

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

There are systems where systems suspend is FAST, except for the sync.
I can e-mail you the analyze_suspend output for such a system.

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

Unfortunately, sys_sync() can be a significant pain point,
even for systems that run Android.

Len Brown, 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/