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

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

[Zhang Rui]

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?

thanks,
rui

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

[Alan Stern]

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

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

[Alan Stern]

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

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

[Rafael J. Wysocki]

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

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

[Rafael J. Wysocki]

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

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

[Pavel Machek]

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

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

[Pavel Machek]

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

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

[Rafael J. Wysocki]

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

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

[Rafael J. Wysocki]

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

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

[Pavel Machek]

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

At least I ran into habit of running "echo mem > /sys/power/state"
manually on zaurus. I guess nontrivial ammount of people have custom
scripts that may or may not sync...

Anyway, if distro already ran sync, additional one is likely to be
very fast.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

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

At least I ran into habit of running "echo mem > /sys/power/state"
manually on zaurus. I guess nontrivial ammount of people have custom
scripts that may or may not sync...

Anyway, if distro already ran sync, additional one is likely to be
very fast.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Alan Stern]

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

Alan Stern

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

[Alan Stern]

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

Alan Stern

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

[Rafael J. Wysocki]

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

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

[Rafael J. Wysocki]

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

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

[Pavel Machek]

> > > 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. :-)

Well, if you can add the choice, without adding anything ugly and with
staying back-compatible, why not. (sync has to stay by default). I
believe ioctls() on /dev/snapshot may already enable you to do s2ram
without sync; if not they could be extended.

But remember there are even in-kernel s2ram triggers, for example on
zaurus when battery goes critical.

(And s2ram without sync _is_ "wrong": writeback timeouts are not
honored).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

> > > 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. :-)

Well, if you can add the choice, without adding anything ugly and with
staying back-compatible, why not. (sync has to stay by default). I
believe ioctls() on /dev/snapshot may already enable you to do s2ram
without sync; if not they could be extended.

But remember there are even in-kernel s2ram triggers, for example on
zaurus when battery goes critical.

(And s2ram without sync _is_ "wrong": writeback timeouts are not
honored).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Henrique de Moraes Holschuh]

On Thu, 14 May 2009, Pavel Machek wrote:
> But remember there are even in-kernel s2ram triggers, for example on
> zaurus when battery goes critical.

Are there?  I am quite interested on this!

Are they safe on x86?

thinkpad-acpi receives some critical alarms from the firmware, for which the
recommended action by the vendor is to go into S3 immediately.  There is
also one which requires S4 as the recommended damage control measure.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

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

[Henrique de Moraes Holschuh]

On Thu, 14 May 2009, Pavel Machek wrote:
> But remember there are even in-kernel s2ram triggers, for example on
> zaurus when battery goes critical.

Are there?  I am quite interested on this!

Are they safe on x86?

thinkpad-acpi receives some critical alarms from the firmware, for which the
recommended action by the vendor is to go into S3 immediately.  There is
also one which requires S4 as the recommended damage control measure.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

suspending machine from kernel (was Re: [linux-pm] [RFC] why do we need run disk sync before entering S3)

[Pavel Machek]

On Thu 2009-05-14 22:00:56, Henrique de Moraes Holschuh wrote:
> On Thu, 14 May 2009, Pavel Machek wrote:
> > But remember there are even in-kernel s2ram triggers, for example on
> > zaurus when battery goes critical.
> 
> Are there?  I am quite interested on this!

Yes.

It is a bit of mess, but see

common/sharpsl_pm.c:

   /* Suspend if critical battery level */
        if ((sharpsl_pm.battstat.ac_status != APM_AC_ONLINE)
                        && (sharpsl_pm.battstat.mainbat_status ==
APM_BATTERY_STATUS_CRITICAL)
                        && !(sharpsl_pm.flags & SHARPSL_APM_QUEUED)) {
                sharpsl_pm.flags |= SHARPSL_APM_QUEUED;
                dev_err(sharpsl_pm.dev, "Fatal Off\n");
                apm_queue_event(APM_CRITICAL_SUSPEND);
        }

it eventually triggers regular s2ram paths.

Older versions did suspend on power button press. (You can't really
turn zaurus _off_, AFAICT.)

> Are they safe on x86?

Well, probably safe but definitely would need some cleanup.

> thinkpad-acpi receives some critical alarms from the firmware, for which the
> recommended action by the vendor is to go into S3 immediately.  There is
> also one which requires S4 as the recommended damage control measure.

While s2ram should always work on hardware that supports it (zaurus),
S4 is more tricky. It needs swap to be configured, and userspace
cooperation in uswsusp case.

I guess sending signal to init would be right solution in that
case. (ACPI already does that on overheat.)

								Pavel
(Sorry about breaking Ccs)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

suspending machine from kernel (was Re: [RFC] why do we need run disk sync before entering S3)

[Pavel Machek]

On Thu 2009-05-14 22:00:56, Henrique de Moraes Holschuh wrote:
> On Thu, 14 May 2009, Pavel Machek wrote:
> > But remember there are even in-kernel s2ram triggers, for example on
> > zaurus when battery goes critical.
> 
> Are there?  I am quite interested on this!

Yes.

It is a bit of mess, but see

common/sharpsl_pm.c:

   /* Suspend if critical battery level */
        if ((sharpsl_pm.battstat.ac_status != APM_AC_ONLINE)
                        && (sharpsl_pm.battstat.mainbat_status ==
APM_BATTERY_STATUS_CRITICAL)
                        && !(sharpsl_pm.flags & SHARPSL_APM_QUEUED)) {
                sharpsl_pm.flags |= SHARPSL_APM_QUEUED;
                dev_err(sharpsl_pm.dev, "Fatal Off\n");
                apm_queue_event(APM_CRITICAL_SUSPEND);
        }

it eventually triggers regular s2ram paths.

Older versions did suspend on power button press. (You can't really
turn zaurus _off_, AFAICT.)

> Are they safe on x86?

Well, probably safe but definitely would need some cleanup.

> thinkpad-acpi receives some critical alarms from the firmware, for which the
> recommended action by the vendor is to go into S3 immediately.  There is
> also one which requires S4 as the recommended damage control measure.

While s2ram should always work on hardware that supports it (zaurus),
S4 is more tricky. It needs swap to be configured, and userspace
cooperation in uswsusp case.

I guess sending signal to init would be right solution in that
case. (ACPI already does that on overheat.)

								Pavel
(Sorry about breaking Ccs)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Rafael J. Wysocki]

On Thursday 14 May 2009, Pavel Machek wrote:
> 
> > > > 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. :-)
> 
> Well, if you can add the choice, without adding anything ugly and with
> staying back-compatible, why not. (sync has to stay by default). I
> believe ioctls() on /dev/snapshot may already enable you to do s2ram
> without sync; if not they could be extended.
> 
> But remember there are even in-kernel s2ram triggers, for example on
> zaurus when battery goes critical.
> 
> (And s2ram without sync _is_ "wrong": writeback timeouts are not
> honored).

OK, so I think the answer is we need the sync() as long as our filesystems
don't support suspend-resume directly.

Thanks,
Rafael

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

[Rafael J. Wysocki]

On Thursday 14 May 2009, Pavel Machek wrote:
> 
> > > > 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. :-)
> 
> Well, if you can add the choice, without adding anything ugly and with
> staying back-compatible, why not. (sync has to stay by default). I
> believe ioctls() on /dev/snapshot may already enable you to do s2ram
> without sync; if not they could be extended.
> 
> But remember there are even in-kernel s2ram triggers, for example on
> zaurus when battery goes critical.
> 
> (And s2ram without sync _is_ "wrong": writeback timeouts are not
> honored).

OK, so I think the answer is we need the sync() as long as our filesystems
don't support suspend-resume directly.

Thanks,
Rafael

Re: suspending machine from kernel (was Re: [linux-pm] [RFC] why do we need run disk sync before entering S3)

[Henrique de Moraes Holschuh]

On Fri, 15 May 2009, Pavel Machek wrote:
> > thinkpad-acpi receives some critical alarms from the firmware, for which the
> > recommended action by the vendor is to go into S3 immediately.  There is
> > also one which requires S4 as the recommended damage control measure.
> 
> While s2ram should always work on hardware that supports it (zaurus),
> S4 is more tricky. It needs swap to be configured, and userspace
> cooperation in uswsusp case.

Yeah, this really calls for issuing some sort of event to userspace that has
the "emergency" connotation, so that desktop enviromnents don't start doing
retarted things like asking the user stupid questions when the machine has
30 seconds left of battery juice, or got waken up from S3 due to a
critically hot thermal alarm.

> I guess sending signal to init would be right solution in that
> case. (ACPI already does that on overheat.)

I will look into this.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: suspending machine from kernel (was Re: [RFC] why do we need run disk sync before entering S3)

[Henrique de Moraes Holschuh]

On Fri, 15 May 2009, Pavel Machek wrote:
> > thinkpad-acpi receives some critical alarms from the firmware, for which the
> > recommended action by the vendor is to go into S3 immediately.  There is
> > also one which requires S4 as the recommended damage control measure.
> 
> While s2ram should always work on hardware that supports it (zaurus),
> S4 is more tricky. It needs swap to be configured, and userspace
> cooperation in uswsusp case.

Yeah, this really calls for issuing some sort of event to userspace that has
the "emergency" connotation, so that desktop enviromnents don't start doing
retarted things like asking the user stupid questions when the machine has
30 seconds left of battery juice, or got waken up from S3 due to a
critically hot thermal alarm.

> I guess sending signal to init would be right solution in that
> case. (ACPI already does that on overheat.)

I will look into this.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

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

[Zhang Rui]

On Fri, 2009-05-15 at 22:36 +0800, Rafael J. Wysocki wrote:
> On Thursday 14 May 2009, Pavel Machek wrote:
> > 
> > > > > 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. :-)
> > 
agree, and this is the purpose of my original post.

> > Well, if you can add the choice, without adding anything ugly and with
> > staying back-compatible, why not. (sync has to stay by default). I
> > believe ioctls() on /dev/snapshot may already enable you to do s2ram
> > without sync; if not they could be extended.
> > 
> > But remember there are even in-kernel s2ram triggers, for example on
> > zaurus when battery goes critical.
> > 

Take ACPI for example, ACPI defines two ACPI battery states, one is
"low" and another is "critical".
OS enters S3/S4 when battery is low, while it performs an emergency
shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
So I'm wondering if it's right to enter S3 when we know that the system
may lost power at anytime.

> > (And s2ram without sync _is_ "wrong": writeback timeouts are not
> > honored).
> 
any kind of suspend can't meet this requirement. Even sys_sync is
called, there is a small window that some pages are dirtied, but are not
synced to disk in max expire interval, right?

thanks,
rui

> OK, so I think the answer is we need the sync() as long as our filesystems
> don't support suspend-resume directly.
> 
> Thanks,
> Rafael

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

[Zhang Rui]

On Fri, 2009-05-15 at 22:36 +0800, Rafael J. Wysocki wrote:
> On Thursday 14 May 2009, Pavel Machek wrote:
> > 
> > > > > 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. :-)
> > 
agree, and this is the purpose of my original post.

> > Well, if you can add the choice, without adding anything ugly and with
> > staying back-compatible, why not. (sync has to stay by default). I
> > believe ioctls() on /dev/snapshot may already enable you to do s2ram
> > without sync; if not they could be extended.
> > 
> > But remember there are even in-kernel s2ram triggers, for example on
> > zaurus when battery goes critical.
> > 

Take ACPI for example, ACPI defines two ACPI battery states, one is
"low" and another is "critical".
OS enters S3/S4 when battery is low, while it performs an emergency
shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
So I'm wondering if it's right to enter S3 when we know that the system
may lost power at anytime.

> > (And s2ram without sync _is_ "wrong": writeback timeouts are not
> > honored).
> 
any kind of suspend can't meet this requirement. Even sys_sync is
called, there is a small window that some pages are dirtied, but are not
synced to disk in max expire interval, right?

thanks,
rui

> OK, so I think the answer is we need the sync() as long as our filesystems
> don't support suspend-resume directly.
> 
> Thanks,
> Rafael

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

[Nigel Cunningham]

Hi.

On Wed, 2009-05-13 at 10:03 +0200, 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.

Sorry for coming into this discussion late - I was unavailable most of
last week.

Another point to remember is that syncing from userspace will not be
guaranteed to stop data loss. To be sure that all of userspace's writes
are synced, we need to do the syncing after userspace has stopped
submitting the writes, which implies after userspace has been frozen.

Regards,

Nigel

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

[Pavel Machek]

Hi!

> > > But remember there are even in-kernel s2ram triggers, for example on
> > > zaurus when battery goes critical.
> > > 
> 
> Take ACPI for example, ACPI defines two ACPI battery states, one is
> "low" and another is "critical".
> OS enters S3/S4 when battery is low, while it performs an emergency
> shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> So I'm wondering if it's right to enter S3 when we know that the system
> may lost power at anytime.

Well, battery only lasts like 30 hours in S3. So if you leave your
notebook unattended for 30 hours, you'll loose recent changes.

> > > (And s2ram without sync _is_ "wrong": writeback timeouts are not
> > > honored).

> any kind of suspend can't meet this requirement. Even sys_sync is
> called, there is a small window that some pages are dirtied, but are not
> synced to disk in max expire interval, right?

Not if you do sys_sync() after freeze of userspace. (I'm not 100% sure
there's no race in there somewhere, but I'd prefer not to make the
race bigger.)
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

Hi!

> > > But remember there are even in-kernel s2ram triggers, for example on
> > > zaurus when battery goes critical.
> > > 
> 
> Take ACPI for example, ACPI defines two ACPI battery states, one is
> "low" and another is "critical".
> OS enters S3/S4 when battery is low, while it performs an emergency
> shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> So I'm wondering if it's right to enter S3 when we know that the system
> may lost power at anytime.

Well, battery only lasts like 30 hours in S3. So if you leave your
notebook unattended for 30 hours, you'll loose recent changes.

> > > (And s2ram without sync _is_ "wrong": writeback timeouts are not
> > > honored).

> any kind of suspend can't meet this requirement. Even sys_sync is
> called, there is a small window that some pages are dirtied, but are not
> synced to disk in max expire interval, right?

Not if you do sys_sync() after freeze of userspace. (I'm not 100% sure
there's no race in there somewhere, but I'd prefer not to make the
race bigger.)
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Oliver Neukum]

Am Freitag, 22. Mai 2009 17:33:57 schrieb Pavel Machek:
> > Take ACPI for example, ACPI defines two ACPI battery states, one is
> > "low" and another is "critical".
> > OS enters S3/S4 when battery is low, while it performs an emergency
> > shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> > So I'm wondering if it's right to enter S3 when we know that the system
> > may lost power at anytime.
>
> Well, battery only lasts like 30 hours in S3. So if you leave your
> notebook unattended for 30 hours, you'll loose recent changes.

Even if the battery is very low you get 30 hours?

	Regards
		Oliver

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

[Oliver Neukum]

Am Freitag, 22. Mai 2009 17:33:57 schrieb Pavel Machek:
> > Take ACPI for example, ACPI defines two ACPI battery states, one is
> > "low" and another is "critical".
> > OS enters S3/S4 when battery is low, while it performs an emergency
> > shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> > So I'm wondering if it's right to enter S3 when we know that the system
> > may lost power at anytime.
>
> Well, battery only lasts like 30 hours in S3. So if you leave your
> notebook unattended for 30 hours, you'll loose recent changes.

Even if the battery is very low you get 30 hours?

	Regards
		Oliver

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

[Pavel Machek]

On Sat 2009-05-23 09:59:22, Oliver Neukum wrote:
> Am Freitag, 22. Mai 2009 17:33:57 schrieb Pavel Machek:
> > > Take ACPI for example, ACPI defines two ACPI battery states, one is
> > > "low" and another is "critical".
> > > OS enters S3/S4 when battery is low, while it performs an emergency
> > > shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> > > So I'm wondering if it's right to enter S3 when we know that the system
> > > may lost power at anytime.
> >
> > Well, battery only lasts like 30 hours in S3. So if you leave your
> > notebook unattended for 30 hours, you'll loose recent changes.
> 
> Even if the battery is very low you get 30 hours?

That will of course be less. 30 hours is really best case, on "good"
notebook.

What I was trying to point out is that even if you go into s3 with
machine fully charged, you'll loose your data after like 30 hours.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

On Sat 2009-05-23 09:59:22, Oliver Neukum wrote:
> Am Freitag, 22. Mai 2009 17:33:57 schrieb Pavel Machek:
> > > Take ACPI for example, ACPI defines two ACPI battery states, one is
> > > "low" and another is "critical".
> > > OS enters S3/S4 when battery is low, while it performs an emergency
> > > shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> > > So I'm wondering if it's right to enter S3 when we know that the system
> > > may lost power at anytime.
> >
> > Well, battery only lasts like 30 hours in S3. So if you leave your
> > notebook unattended for 30 hours, you'll loose recent changes.
> 
> Even if the battery is very low you get 30 hours?

That will of course be less. 30 hours is really best case, on "good"
notebook.

What I was trying to point out is that even if you go into s3 with
machine fully charged, you'll loose your data after like 30 hours.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Oliver Neukum]

Am Samstag, 23. Mai 2009 10:50:18 schrieb Pavel Machek:
> On Sat 2009-05-23 09:59:22, Oliver Neukum wrote:
> > Am Freitag, 22. Mai 2009 17:33:57 schrieb Pavel Machek:
> > > > Take ACPI for example, ACPI defines two ACPI battery states, one is
> > > > "low" and another is "critical".
> > > > OS enters S3/S4 when battery is low, while it performs an emergency
> > > > shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> > > > So I'm wondering if it's right to enter S3 when we know that the
> > > > system may lost power at anytime.
> > >
> > > Well, battery only lasts like 30 hours in S3. So if you leave your
> > > notebook unattended for 30 hours, you'll loose recent changes.
> >
> > Even if the battery is very low you get 30 hours?
>
> That will of course be less. 30 hours is really best case, on "good"
> notebook.
>
> What I was trying to point out is that even if you go into s3 with
> machine fully charged, you'll loose your data after like 30 hours.
> 									Pavel

Hi,

OK, I see so this was an argument for syncing. Sorry for misunderstanding.
But we'd still loose RAM. Which makes me wonder whether S3 and STD
really need to be mutually exclusive. Couldn't we write a snapshot to disk
just in case. All it would take is the STR code to mark the snapshot invalid
before any alteration of the filesystems.

	Regards
		Oliver

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

[Oliver Neukum]

Am Samstag, 23. Mai 2009 10:50:18 schrieb Pavel Machek:
> On Sat 2009-05-23 09:59:22, Oliver Neukum wrote:
> > Am Freitag, 22. Mai 2009 17:33:57 schrieb Pavel Machek:
> > > > Take ACPI for example, ACPI defines two ACPI battery states, one is
> > > > "low" and another is "critical".
> > > > OS enters S3/S4 when battery is low, while it performs an emergency
> > > > shutdown when battery is in critical state. (ACPI spec 3.0b 3.9.4)
> > > > So I'm wondering if it's right to enter S3 when we know that the
> > > > system may lost power at anytime.
> > >
> > > Well, battery only lasts like 30 hours in S3. So if you leave your
> > > notebook unattended for 30 hours, you'll loose recent changes.
> >
> > Even if the battery is very low you get 30 hours?
>
> That will of course be less. 30 hours is really best case, on "good"
> notebook.
>
> What I was trying to point out is that even if you go into s3 with
> machine fully charged, you'll loose your data after like 30 hours.
> 									Pavel

Hi,

OK, I see so this was an argument for syncing. Sorry for misunderstanding.
But we'd still loose RAM. Which makes me wonder whether S3 and STD
really need to be mutually exclusive. Couldn't we write a snapshot to disk
just in case. All it would take is the STR code to mark the snapshot invalid
before any alteration of the filesystems.

	Regards
		Oliver

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

[Pavel Machek]

Hi!

> > That will of course be less. 30 hours is really best case, on "good"
> > notebook.
> >
> > What I was trying to point out is that even if you go into s3 with
> > machine fully charged, you'll loose your data after like 30 hours.
> 
> OK, I see so this was an argument for syncing. Sorry for
> misunderstanding.

Yes; we need to sync.

> But we'd still loose RAM. Which makes me wonder whether S3 and STD
> really need to be mutually exclusive. Couldn't we write a snapshot to disk
> just in case. All it would take is the STR code to mark the snapshot invalid
> before any alteration of the filesystems.

suspend.sf.net, program s2both :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

Hi!

> > That will of course be less. 30 hours is really best case, on "good"
> > notebook.
> >
> > What I was trying to point out is that even if you go into s3 with
> > machine fully charged, you'll loose your data after like 30 hours.
> 
> OK, I see so this was an argument for syncing. Sorry for
> misunderstanding.

Yes; we need to sync.

> But we'd still loose RAM. Which makes me wonder whether S3 and STD
> really need to be mutually exclusive. Couldn't we write a snapshot to disk
> just in case. All it would take is the STR code to mark the snapshot invalid
> before any alteration of the filesystems.

suspend.sf.net, program s2both :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Oliver Neukum]

Am Samstag, 23. Mai 2009 11:45:18 schrieb Pavel Machek:
> suspend.sf.net, program s2both :-).

Cool. What happens if you crash after unfreezing user space but before you
declare the image invalid?

	Regards
		Oliver

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

[Oliver Neukum]

Am Samstag, 23. Mai 2009 11:45:18 schrieb Pavel Machek:
> suspend.sf.net, program s2both :-).

Cool. What happens if you crash after unfreezing user space but before you
declare the image invalid?

	Regards
		Oliver

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

[Pavel Machek]

On Sun 2009-05-24 23:02:55, Oliver Neukum wrote:
> Am Samstag, 23. Mai 2009 11:45:18 schrieb Pavel Machek:
> > suspend.sf.net, program s2both :-).
> 
> Cool. What happens if you crash after unfreezing user space but before you
> declare the image invalid?

I'd have to check the code to make sure, but it should first kill the
image and then unfreeze :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pavel Machek]

On Sun 2009-05-24 23:02:55, Oliver Neukum wrote:
> Am Samstag, 23. Mai 2009 11:45:18 schrieb Pavel Machek:
> > suspend.sf.net, program s2both :-).
> 
> Cool. What happens if you crash after unfreezing user space but before you
> declare the image invalid?

I'd have to check the code to make sure, but it should first kill the
image and then unfreeze :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Zhang Rui]

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?

thanks,
rui