On Mon, 1 Aug 2005, Amit Kucheria wrote: > Per-device idle-timeouts are IMHO important in embedded space where one > wants finer-grained control. e.g. Sometimes it might be better to just > let a device be active to avoid wake-up latencies from power-save mode. > Also, some application usage profiles might dictate changes in > idle-timeout values to allow optimisation for the common use-cases. There's no question about having per-device idle timeouts, or about letting userspace set the timeout values (or make the value be infinite so there is no idle timeout ever). The question is how to implement them: using kernel timers or using a kernel thread? Note that having some sort of thread available will be necessary in any case, since the actual suspend/resume function calls require a process context. > Whether the idle-timeout is implemented using kernel timers or a kernel > thread checking for timeout values, is a more difficult question. > Ideally, we would want to avoid unnecessary (processor) wakeups simply > to check a list of timeout values. Dynamic tick patch allows us to > wakeup the processor only when there is work to do - timers set to go > off. So, that's one strike against the kernel thread approach. > > But it needs more thinking. Yes, it's complex. Constantly updating the timer expirations every time a device carries out an activity can also be expensive. > If I tell a bus to power down, couldn't the PM framework take care of > recursively sending 'power down' message to all children, wait for > confirmation, and then power itself down? Well sure, we _could_. The question is, _should_ we? Or should the kernel force you to tell each of the bus's children to power down before telling the bus? Alan Stern
