On Wed, Jul 22, 2015 at 4:55 AM, Oliver Neukum <oneu...@suse.com> wrote:
> On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote:
>> And it is more pain for me to change the user space on each of them to
>> write to the new sysfs file on every boot than to set a kernel Kconfig
>> option once.
>
> So why at all? If you really need this in sysfs, why not write
> something like "memfast" into /sys/power/state ?
We fought this battle, and lost.
When we came out with "freeze", which is faster than "mem",
no user-space changed to take advantage of it.
"mem" is what they use on all platforms, and they simply want it to be fast.
I don't like the run-time sysfs attribute in this patch.
There are only 4 use-cases, and we can handle the 3 that matter
without a sysfs attribute:
1. OS wants sync, run-time never changes mind
compile kernel with sync
this is default, and what everybody is accustomed to.
2. OS does not want sync, run-time never changes mind
compile kernel without sync
This gives OS' that care about suspend/resume latency what they want.
I'm fine with Austin's suggestion "depends on EXPERT"
3. OS wants sync, run-time wants to opt-OUT
Sorry, we'll not support his case.
If your run a distro kernel that builds in the sync, you are stuck with it.
If you care, then build a kernel from scratch, or run a different distro.
4. OS does not want sync, run-time sometimes wants to opt-IN
As it turns out, Linux kernel has always invoked sync before freezing
user-threads. Sorry, invoking sync in kernel suspend path does not close
a race that isn't also currently present by invoking sync from user-space.
(yes, as discussed, the proper long term fix involves notifying file systems)
As this user will not have a sysfs attribute to tweak to tell the
kernel to sync,
they can simply invoke sync from user-space.
thanks,
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
