public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Pavel Machek <pavel@ucw.cz>,
	linux-pm@lists.linux-foundation.org,
	Zhang Rui <rui.zhang@intel.com>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	Len Brown <lenb@kernel.org>
Subject: Re: [linux-pm] [RFC] why do we need run disk sync before entering S3
Date: Wed, 13 May 2009 16:16:26 +0200	[thread overview]
Message-ID: <200905131616.27334.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0905131000360.3004-100000@iolanthe.rowland.org>

On Wednesday 13 May 2009, Alan Stern wrote:
> On Wed, 13 May 2009, Rafael J. Wysocki wrote:
> 
> > > > I generally agree, but I think we may also leave the syncing to the user space,
> > > > in both cases.
> > > 
> > > Well...
> > > 
> > > Normally kernel writes dirty data to disk each 30
> > > seconds. s2ram/s2disk breaks that promise, so it seems fair to add
> > > explicit sync to keep the "promise".
> > > 
> > > OTOH, I agree it would be more flexible if we left sync to
> > > userspace. In uswsusp case, it actually makes sense. In s2ram
> > > case... if we can do it while keeping compatibility with old
> > > behaviour... why not.
> > 
> > That really depends on the distrubution.  (open)SUSE always syncs before
> > suspend/hibernation AFAICS, but I don't know about the other distros.
> 
> This doesn't address the real question: Should the system be allowed to 
> go into S3 without doing a sync first?
> 
> Whether the sync is initiated by userspace or by the kernel doesn't 
> make any difference.  Likewise, it doesn't matter if there are two 
> syncs (because the second will be very fast, as Pavel said).
> 
> If you really wanted to speed up the suspend transition then you would
> leave out the sync entirely.  But IMO this would be a mistake; the risk
> of data loss is too great.  Which means the time overhead is necessary,
> one way or another.  If userspace does a sync first then the suspend
> transition will be faster, but this is just an accounting artifact (do
> you count the time required for the sync toward the time required for
> the suspend or not).

My point was in fact that if we left the syncing to the user space, then the
user would be able to decide not to sync risking data loss.  At the moment the
user has no choice. :-)

Thanks,
Rafael

  reply	other threads:[~2009-05-13 14:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-13  1:20 [RFC] why do we need run disk sync before entering S3 Zhang Rui
2009-05-13  2:01 ` [linux-pm] " Alan Stern
2009-05-13  8:03   ` Rafael J. Wysocki
2009-05-13  8:45     ` Pavel Machek
2009-05-13  8:53       ` Rafael J. Wysocki
2009-05-13  8:57         ` Pavel Machek
2009-05-13 14:06         ` Alan Stern
2009-05-13 14:16           ` Rafael J. Wysocki [this message]
2009-05-14  9:42             ` Pavel Machek
2009-05-15  1:00               ` Henrique de Moraes Holschuh
2009-05-15  9:08                 ` suspending machine from kernel (was Re: [linux-pm] [RFC] why do we need run disk sync before entering S3) Pavel Machek
2009-05-15 21:15                   ` Henrique de Moraes Holschuh
2009-05-15 14:36               ` [linux-pm] [RFC] why do we need run disk sync before entering S3 Rafael J. Wysocki
2009-05-18  7:25                 ` Zhang Rui
2009-05-22 15:33                   ` Pavel Machek
2009-05-23  7:59                     ` Oliver Neukum
2009-05-23  8:50                       ` [linux-pm] [RFC] why do we need run disk sync before entering?S3 Pavel Machek
2009-05-23  9:05                         ` Oliver Neukum
2009-05-23  9:45                           ` Pavel Machek
2009-05-24 21:02                             ` Oliver Neukum
2009-05-24 21:14                               ` Pavel Machek
2009-05-19  1:03     ` [RFC] why do we need run disk sync before entering S3 Nigel Cunningham

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=200905131616.27334.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@ucw.cz \
    --cc=rui.zhang@intel.com \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox