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

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

 



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.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux