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. Alan Stern -- 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
