From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Brown, Len" <len.brown@intel.com>,
Austin S Hemmelgarn <ahferroin7@gmail.com>,
Len Brown <lenb@kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
Date: Tue, 21 Jul 2015 11:38:06 +0200 [thread overview]
Message-ID: <20150721093806.GA23841@amd> (raw)
In-Reply-To: <1684935.fYtBRJbzgO@vostro.rjw.lan>
On Sat 2015-07-18 01:54:09, Rafael J. Wysocki wrote:
> On Wednesday, July 15, 2015 02:58:22 PM Brown, Len wrote:
> >
> > > -----Original Message-----
> > > From: Austin S Hemmelgarn [mailto:ahferroin7@gmail.com]
> > > Sent: Wednesday, July 15, 2015 10:07 AM
> > > To: Pavel Machek; Len Brown
> > > Cc: rjw@rjwysocki.net; linux-pm@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; Brown, Len
> > > Subject: Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
> > >
> > > On 2015-07-15 02:43, Pavel Machek wrote:
> > > > On Tue 2015-07-14 22:24:51, Len Brown wrote:
> > > >> From: Len Brown <len.brown@intel.com>
> > > >>
> > > >> The Linux kernel suspend path has traditionally invoked sys_sync().
> > > >>
> > > >> But sys_sync() can be expensive, and some systems do not want
> > > >> to pay the cost of sys_sync() on every suspend.
> > > >
> > > > Have you measured how expensive it can be, and why it is expensive?
> >
> > > How expensive it is can vary widely, but it pretty much boils down to
> > > how much dirty data still needs written out, and how slow the storage it
> > > needs written to is. There's not really much that can be done in the
> > > kernel to change this, and most userspace suspend systems call sync
> > > themselves during the suspend sequence.
> >
> > Right.
> > And now, user-space gets is no longer forced to incur that
> > delay on every suspend if they do not want it.
> >
> > Yes, have measured this under many conditions.
> > The bottom line is that sys_sync() is rarely as fast as 1ms,
> > and is sometimes as slow as hundreds of ms.
..and failed to figure out what is going on there. Yes, sync needs to
be slow if there's a lot of data to write. But if you suspend
frequently, there should not be a lot of data to write. (And you
should not be suspending with ton of dirty data in the first place).
> > >> Why do you need CONFIG parameter?
> >
> > So that an OS that doesn't want to change their user-space,
> > can build a kernel that does what they want by default.
> >
> > Originally I had the config parameter remove this code entirely,
> > which would achieve the same goal.
> > But Rafael prefers the sysfs attribute always exist
> > and the config simply set the default.
>
> Indeed.
>
> And so I'm queuing this patch up for 4.3 (with a couple of minor fixups).
Please don't.
"OS that doesn't want to change the user-space to speed up suspend by
few milliseconds" is not a valid reason for asking about million users
one more config question. Affected users can't run mainline kernel
anyway, and will have to change their userland in non-trivial ways to
get there.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2015-07-21 9:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 2:24 [PATCH v4 0/1] suspend: make sync() on suspend-to-RAM optional Len Brown
2015-07-15 2:24 ` [PATCH 1/1] " Len Brown
2015-07-15 6:43 ` Pavel Machek
2015-07-15 14:06 ` Austin S Hemmelgarn
2015-07-15 14:58 ` Brown, Len
2015-07-17 23:54 ` Rafael J. Wysocki
2015-07-21 9:38 ` Pavel Machek [this message]
2015-07-21 14:41 ` Rafael J. Wysocki
2015-07-21 15:19 ` Pavel Machek
2015-07-21 15:36 ` Austin S Hemmelgarn
2015-07-21 20:11 ` Pavel Machek
2015-07-21 20:01 ` Brown, Len
2015-07-21 20:05 ` Pavel Machek
2015-07-22 1:25 ` Rafael J. Wysocki
2015-07-22 7:23 ` Pavel Machek
2015-07-22 8:55 ` Oliver Neukum
2015-07-31 16:02 ` Len Brown
2015-07-31 23:56 ` Rafael J. Wysocki
2015-10-08 15:50 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2014-01-23 7:11 Len Brown
2014-01-23 7:29 ` Zhang Rui
2014-01-23 7:41 ` Brown, Len
2014-01-23 7:41 ` Brown, Len
2014-01-23 7:38 ` Srivatsa S. Bhat
2014-01-23 7:59 ` Brown, Len
2014-01-26 21:08 ` Pavel Machek
2015-05-08 6:41 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150721093806.GA23841@amd \
--to=pavel@ucw.cz \
--cc=ahferroin7@gmail.com \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.