linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTin245wZsxeUh2HuONHqDNXFWpyzPsYv4PPuZYSb@mail.gmail.com>
Date:	Thu, 5 Aug 2010 17:29:24 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Matthew Garrett <mjg59@...f.ucam.org>, david@...g.hm,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

2010/8/5 Rafael J. Wysocki <rjw@...k.pl>:
>>
>> 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.

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.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/