Hi Frank, >> In the future, we can imagine setting wakeups programmatically, >> with the help of the Linux dynamic ticks implementation and the >> cpuidle framework -- if Frank's sugar clock has a pending wakeup >> in 60 seconds to update the minute hand of the clock, we can set a >> wakeup for +59s before going to sleep. This is a long-term >> feature, though.
> To what extent do folks know what olpc userspace is doing in its > idle moments? If there is not much junk system call traffic, one > could imagine a tool that monitors the processes, and when it finds > that they're all voluntarily sleeping for "long enough", it could > schedule an early suspend and a later automatic resume. i.e., if > sugar clock is doing sleep(60), but other processes are blocked on > I/O, this tool could run "rtcwakeup 60; echo mem > /proc/.../suspend"). That's what I meant by my para. above, but we don't need to do this filtering in userspace -- dynticks provides us data on which pids have wakeups set and when the wakeups will fire. (See /proc/timer_list.) But first we need to make sure userspace is quiesced when the user is not using the machine. It's very difficult to remove all unnecessary polling and wakeups, but that's what we should try to do. We've tried to avoid unnecessary polling in both UI design and implementation; as an example of how we've been preferring interrupt-based solutions, the way our battery status monitor on the sugar home view works is: * when the current battery capacity changes by one percent, the embedded controller fires an interrupt * the kernel picks up the interrupt and exposes the change to HAL * HAL broadcasts the level change over dbus * Sugar listens to the dbus stream, picks up the new battery value from HAL and renders it. There's an alternative answer to the question of how we handle future events, and it's that low-power computing requires no longer thinking of your computer as something that runs at full-power every minute of the day just waiting for your crontab to fire. The computer's going to be turned off a lot of the time, even when it doesn't look to you like it's obviously off, and that's just something people writing software for the XO will have to change the way they program for. I'm not yet sure how reasonable this answer is. :) Thanks, - Chris. -- Chris Ball <[EMAIL PROTECTED]> _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel