Messages in this thread | | | Subject | Re: uptime increases during suspend | From | john stultz <> | Date | Mon, 27 Mar 2006 10:40:20 -0800 |
| |
On Sat, 2006-03-25 at 16:02 +0100, Jonathan Black wrote: > I'd like to enquire about the following behaviour: > > $ uptime && sudo hibernate && uptime > 14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42 > 14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91 > > I.e. the system was suspended to disk for 5 minutes, but the value > reported by 'uptime' has increased by as much, as if it had actually > continued running during that time.
Yes, I don't know exactly when it was changed, but jiffies is now updated when we return from suspend, which causes the uptime to effectively increase while we are suspended.
[snip] > The way it is now, one can essentially "cheat": suspend a machine, put > it in the cupboard for a couple of weeks, resume it and claim a > respectable uptime, because the uptime value only reflects how long ago > the system was first booted up, with no regard to how much of that time > it has actually been running.
Well, anyone can hack their kernel to say whatever uptime they want, so I'm not to worried about cheating. Are you seeing an actual bug here?
> Would it be possible to get the old behaviour back?
Why exactly do you want this behavior? Maybe a better explanation would help stir this discussion.
The question about the correct behavior is more relevant with virtualization as well. Should the OS's uptime increase even when another OS is running on the cpu? What is the proper interface to export the OS's cpu time?
Right now I'm of the opinion that jiffies should be updated, as real time has past and timer events that are queued should expire.
However with a good enough reason, we might want to add another counter that keeps track of how much time we've been suspended as well.
thanks -john
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |