On Tue, Jun 30, 2015, at 17:04, Len Brown wrote:

quoted

Entering "mem" suspend mode through sysfs currently has the implied meaning
of "prepare the *entire* system to stay on a powered down state for
pontentially a _long_ time", where long means "certainly more than 10
seconds" ;-) This is unlikely to be written anywhere, of course, that's just
how it was used by the vast majority for years, at least on traditional
server/desktop/laptop platforms such as x86.

The _vast_ majority of systems using Linux suspend today are under
an Android user-space.  Android has no assumption that that suspend to
mem will necessarily stay suspended for a long time.

Indeed, however your change was not android-specific, and it is not
"comfortable" on x86-style hardware and usage patterns.

quoted

IMO, we would actually benefit from *adding* new system-wide sleep/suspend
modes that are optimized for oportunistic, short-lived system-wide sleep
cycles (aka "catnap") that is fast to enter and exit from, and which will be
triggered very frequently, instead of trying to change the assumptions and
expected behavior of the current "deep-sleep" mode...

Thank you for sharing your opinion.

I am going to give up trying to change your mind, and those who share
your view.  I plan to revive my patch from 2014 which
makes sys_sync() optional.  That will not change the historic behavior,
and will still allow everybody to do what they want.
Rafael has said that he can live with the resulting kernel clutter.

...

BTW. the answer does not appear to be creating a new system sleep state.
Android invokes "mem", and they don't seem excited about teaching
user-space that runs on multiple platforms that  what used to be a "mem" and no
"freeze" could be a "mem" plus a "freeze", or a "freeze" and no "mem".

Hmm, maybe we could:

1. Make the behavior of "mem" configurable (select default at compile
time, allow it to be changed at runtime).

2. Add a way to always enter the "heavyweight" (x86-style) mem sleep in
platforms where it exists.

3. Add a way to always enter the "light" (android-style) mem sleep in
platforms where it exists.

And make (2) and (3) optional (as in: you can compile out the clutter). 
That at least provides a way forward for userspace, at the price of more
gunk on the kernel side.

We already have a lot of stuff that works that way (idle and freq
governors, io elevators, etc).

That said, as long as x86 will still try to safeguard my data during mem
sleep/resume as it does today, I have no strong feelings about
light/heavy-weight "mem" sleep being strictly a compile-time selectable
thing, or a more flexible runtime-selectable behavior.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh