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. Thanks, Rafael -- 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
