On Thu, Aug 05, 2010 at 05:29:24PM -0700, Brian Swetland wrote: > 2010/8/5 Rafael J. Wysocki <rjw@xxxxxxx>: > >> > >> Our wakelock stats currently have > >> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time > >> and last_change. Not all of these are equally important (total_time is > >> most important followed by active_since), but you only have count. > >> Also as discussed before, many wakelocks/suspendblockers are not > >> associated with a struct device. > > > > OK > > > > How much of that is used in practice and what for exactly? > > > > Do you _really_ have to debug the wakelocks in drivers that much? > > Debugging power related issues is pretty critical to building > competitive mobile devices. > > Throughout the several months of this discussion I have been > continually scratching my head at this "debugability considered > harmful" attitude that I see in reaction to our interest in having the > ability (gated behind a config option even -- really, that'd be fine, > not everyone need enable it) to gather useful stats and examine the > state of the system. In my case, it has not been "debuggability considered harmful", but rather my lack of understanding of the kinds of bugs that can arise and what information is most helpful in tracking them down. Arve's post listing the meanings of the stats helped me quite a bit, although I am sure that my understanding is still quite rudimentary. > At this point it sounds like there's no interest in the solution we > have, which works and has worked for a few years, and has been revised > 10+ times based on feedback here, and no interest in providing a > solution that accomplishes similar functionality, so perhaps it's time > for us to cut our losses and just go back to maintaining our patches > instead of having the same arguments over and over again. And this brings up another aspect of Android requirements. Mainlining Android features is not necessarily an all-or-nothing proposition. Here is a prototype list of degrees of mainlining, along with at least a few of the benefits and difficulties of each level: o Mainline that provides exactly what Android needs. This is of course the best case, but, as you may have noticed, might not be easy to achieve. The plain fact is that Linux must support a wide variety of workloads, so some give-and-take is usually required. o Mainline that exactly matches the ideal API, but which fails to implement some feature or another. This is still not bad. You have to carry a specific patch to provide the feature(s), but all the calling sites are carried upstream in mainline. o Mainline provides something that is close to the ideal API, but some additional constant arguments are required. This is not so good, but at least the drivers can be upstreamed and the changes required to get to an Android-ready kernel are fairly simple. o Mainline provides something, but Android requires changes to the supplied API which require additional data to be passed from call site to call site. Again, at least drivers can be upstreamed, but the changes required to get to an Android-ready kernel are a bit more involved. o Mainline provides a stubbed-out API. Once again, the drivers can at least be upstreamed, but Android is the only project validating the placement of calls to the API. This means that changes to the drivers are likely to mess up the placement of the call sites. Therefore, getting to an Android-ready kernel requires careful inspection of the drivers to adjust for bugs introduced by others. o Mainline provides nothing. Status quo. This means that some other group will likely introduce the required functionality in an incremental fashion. This process will likely fail to take Android's needs into account, probably leading to... o Mainline provides functionality that is similar to what Android needs, but in a completely incompatible manner that cannot be used easily (or perhaps at all) by Android. My guess is that there is value to Android in a number of the non-perfect cases. Thanx, Paul _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
