On Friday, August 06, 2010, 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. Well, I don't think anyone will disagree with that. > 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. The problem is what kind of stats would be actually sufficient and we haven't seriously discussed that. You said you'd need statistics and we took that for granted, but we didn't really go into details here. > 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. Please remember that I also have spent considerable amount of time trying to push your solution upstream and defending it. I might have spent that time on other things instead, so please don't tell me about "losses". If you want to stay in your ivory tower, that's perfectly fine by me, but I guess that won't really benefit anyone in the long run. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
