[Nexus 7 General] bftb0:
I'll answer this one first since it is easiest. "dmesg" is almost the same thing as "cat /proc/kmsg". The only thing is, the latter command will hang, waiting for more output to be written by the kernel. Or, put another way - "dmesg" gives you the kernel log.

The way I collected those timing statistics was sort of quirky. Without hitting the enter key, I pre-typed in the command

adb shell dmesg > kernel_log.txt

(Note I get a root shell with adb shell due to ro.secure=0 in /default.prop - I have a tweaked boot image)

and then timed Antutu as it ran. As soon as the benchmark finished, I hit the enter key on the PC. This produces a log file with more info in it than I need, but because the messages are timestamped, I could go backwards in time from the last line in the file to find the approximate beginning of the benchmark, and then cut out everything before that. I did a little macro-editing (emacs) to clean up the log file a little so that rather than this:

<4>[19302.347655] cpu_up(1)+^M
<4>[19302.372442] CPU1: Booted secondary processor^M
<4>[19302.375334] cpu_up(1)-^M
...

the log file was a little cleaner and looked like this

302.347 cpu_up(1)+
302.372 CPU1: Booted secondary processor
302.375 cpu_up(1)-
...

and then piped the filtered output through a short awk script

e.g from my (cygwin) shell history:

grep 'CPU[1-3]:' kernlog2.txt | awk '{t=$1+0.0;cpu=$2;};/Booted/{ts[cpu]=t;};/shutdown/{tc[cpu]+=t-ts[cpu];};END{print tc["CPU1:"], tc["CPU2:"], tc["CPU3:"];}'

I'm sure this seems like a lot of work to most, but it doesn't disturb the system under test the way some random "measure the number of online CPUs" app would - that would add additional runnable threads and probably artificially inflate the number of CPUs online at any given moment.

OK, next question.

TL;DR Yes and No.

The question you ask requires a great deal of work to answer in any detail. But I can give you an idea about what is involved in finding out, along with some pointers to making the job easier.

There is a script called "extract-ikconfig" floating around the internet (Unix shell script, possibly would work with Cygwin though). What this does is allow you to extract the Linux "config.gz" file out of a kernel image without needing to actually boot the kernel up (and get it from /proc/config.gz). There are variants of this script - the newer ones support a variety of kernel compression types (gz,bz2,lzma, etc).

This gives you the opportunity to download someones kernel image and see what compile flags are used to build that kernel. For instance, in the case of EDP, look for

CONFIG_TEGRA_EDP_LIMITS

CONFIG_TEGRA_INTERNAL_TSENSOR_EDP_SUPPORT

CONFIG_TEGRA_EDP_EXACT_FREQ

But wait, not so fast! Some of the kernel devs ship complete boot partition images - not bare kernel images. In those cases, you will first need to dig the kernel image out of the boot image first, before you can run "extract-ikconfig" on it. One of the ways this is done is with a perl script called "split_bootimg.pl". You can find an explanation and download the script here on this wiki

OK, so far so good. Now I have showed you how to determine if a kernel dev used a particular configuration flag to build a feature into their kernel. (Note you can use this same procedure for examining kernels for support of CIFS, NTFS, etc)

As it turns out, I looked at a sample of about 6 or 8 kernels a month or two back, and I noticed that only one of them hand turned off CONFIG_TEGRA_EDP_LIMITS in their build. Unfortunately, I can not locate my notes; I probably nuked them in a random disk drive cleanup. So I can't remember which kernel it was at this time (possibly "lean kernel"???).

Whew.

Unfortunately there is more to this story, and it is perhaps the bottom line here: there is nothing to prevent a given kernel dev from altering things in their own source tree. And especially when there are related changes going on (overclocking and undervolting) in their custom kernels, you actually can not be sure that seeing CONFIG_TEGRA_EDP_LIMITS show up in a given kernel's /proc/config.gz file means that compile option implies the same behavior from kernel to kernel. Moreover, you would probably have to examine the git repository branch source history (timestamps) and commit tags carefully to find out which source change corresponds to which release version of a given devs kernel.

There are only two recourses at this point:

(A) Start reading and comparing the source codes in the dev's public git trees, OR

(B) Ask the devs in their kernel threads one by one about the issue.

For the related code, start with these kernel sources

arch/arm/mach-tegra/board-grouper.c

arch/arm/mach-tegra/board-grouper-power.c

arch/arm/mach-tegra/tegra3_thermal.c

arch/arm/mach-tegra/cpu-tegra.c

arch/arm/mach-tegra/cpu-tegra.h

arch/arm/mach-tegra/board-grouper-power-ti.c

arch/arm/mach-tegra/include/mach/thermal.h

arch/arm/mach-tegra/include/mach/edp.h

e.g. here is Metallice's Stable mr1.1 git repository for the above code. And in particular, you can look at cpu-tegra.c revision history on that branch to see that there is both Motley and Metallice changes in it's history.

Whew. I hope that gives you a sense about how a simple question can have an incredibly complicated answer if you are after fine-grained detail.

But BTW, I do understand your question at it's fundamental level - we would prefer to know that a performance (or battery) benchmark analysis was designed to compare code improvement, not random differences in clocking speed bin occupancy. (You may have seen my earlier comments in this thread about normalizing performance values to Fmax. When you do simplistic Fmax normalizations, all the kernels look the same to within 10% or so on the performance benchmark.)

Something to note is that - assuming the CPU count % numbers that I gave above are correct for the Antutu benchmark - we still don't know what weighting the Antutu devs assign to each component of their benchmark score. So, even if we knew exactly how many clock ticks occured in each frequency bin during each component of their benchmark, it would still be impossible to normalize to an "exact average frequency" because the Antutu weightings are unknown.

cheers