Re: [RFC] why do we need run disk sync before entering S3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 13 May 2009, Pavel Machek wrote:
> On Wed 2009-05-13 10:03:14, Rafael J. Wysocki wrote:
> > On Wednesday 13 May 2009, Alan Stern wrote:
> > > On Wed, 13 May 2009, Zhang Rui wrote:
> > > 
> > > > Hi, all,
> > > > 
> > > > I did some S3 tests on an eeepc901, the total suspend time(from issue
> > > > the suspend command to power down) is about 2.5s~3s.
> > > > something interesting is that kernel runs disk sync before entering S3
> > > > state, and this takes about 0.7~1.2s.
> > > > my question is that, why do we need this for s2ram?
> > > > can we remove this and run sys_sync for S4 only?
> > > 
> > > At the risk of sounding foolish, I'd guess that a system in S3 (or more
> > > generally, suspend-to-RAM) is a lot more at risk of losing power or
> > > failing to restore than a normally running system.  (A normally running
> > > system is trivially not at risk of failing to restore!)  Consequently
> > > it makes sense to flush the I/O buffers before entering this state, to
> > > minimize the potential for loss of data.
> > > 
> > > When you think about it, a system in S4 is actually _less_ likely to 
> > > run into trouble than one in S3, since it can't fail because of loss of 
> > > power.  So if anything, we should remove the disk sync from hibernation 
> > > and leave it in system suspend.
> > 
> > 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.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux