On Tue, Mar 3, 2009 at 5:57 AM, Pavel Machek <pavel@xxxxxx> wrote: > Hi! > >> >> If you ignore wakelocks with timeouts, the current >> >> wakelock interface can be implemented with a global atomic_t to >> >> prevent suspend, and a per wakelock atomic_t to prevent a single >> >> client from changing the global reference count by more than one. >> >> >> >> There are a couple of reasons that I have not done this. It removes >> >> the ability to easily inspect the system when it is not suspending. >> > >> > Care to elaborate? >> >> If you have a single atomic_t and it is not 0, you do not know who >> incremented it. > > Which is okay for already debugged system. For debugging, yes some > support can be nice. Yes, but installing an app can turn your debugged system into an undebugged system. I think is fine to have a kernel option to disable all debugging support, I just don't think it is the top priority. I have two options for making the no-stats no-timeout configuration faster. Option one, always use a reference count, and implement the other configurations on top of this. This makes the shipping configuration slower. Option two, use a completely separate implementation when stats or timeouts are enabled. This makes the fast version virtually untested. Neither of these are very appealing at the moment. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm