[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150512223407.GB4316@dastard>
Date: Wed, 13 May 2015 08:34:07 +1000
From: Dave Chinner <david@...morbit.com>
To: Len Brown <lenb@...nel.org>
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 Mon, May 11, 2015 at 04:22:26PM -0400, Len Brown wrote:
> On Sun, May 10, 2015 at 9:44 PM, Dave Chinner <david@...morbit.com> wrote:
>
> > ...Please explain what your use case is that makes this
> > so prohibitively expensive it needs to be removed.
>
> wake on packet, process packet without turning on the display,
> immediately suspend. Do this potentially several times per second.
The sync should almost always be a no-op because the filesystems
should be clean. In that case, where's the latency coming from? If
filesystems were dirtied during the wake period, then we do care
that they get sync'd properly before suspend.
FWIW, I don't think that s2ram or s2d were designed for this
sort of abuse - they really were designed around laptop use cases,
which is what I mostly care about...
> >> 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.
> >
> > So, you want to have s2disk write all the dirty pages in memory to
> > the suspend image, rather than to the filesystem?
>
> The s2disk utility is unchanged by this proposal, it already includes a sync().
Not everyone uses that utility.
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
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/
Powered by blists - more mailing lists