Re: suspend to ram order of operations

On Mon, Mar 30, 2020 at 11:16 AM pdev embedded [off-list ref] wrote:

In reading through the archives, I found the discussion of sys_sync()
and making the call optional, but I am still searching for a discussion
of why the operations are ordered the way they are.
1.) (optionally) sys_sync
2.) freeze user space
3.) freeze kernel threads

On an embedded system running Android where there are user space
processes (not under wakelock control) that generate a lot of IO,
freezing user space first helps reduce the time taken by sys_sync().
I believe this is because buffers are no longer being continually dirtied.

What was the rationale for the ordering of operations when suspending to ram?

The freezing of user space and the freezing of kernel threads were one
operation to start with and filesystems could not be frozen before
that.

IIRC, nobody argued for an ordering change, so it stayed the way it had been.

If there is a lot of user-space filesystem activity, would
it not result in fewer dirty filesystem pages if enter_state()
ordered the operations as:
1.) freeze user space
2.) sys_sync
3.) freeze kernel threads

What am I missing?

Probably the fact that you don't need the sync at all if suspend is
reliable enough.

Or if you want to be extra safe, it is better to trigger the sync from
user space on a regular basis IMO.