[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled

Curiouser and curiouser.
I have a second dn2800mt machine that my girlfriend uses. I ran some tests while there and I'm more uncertain than ever about what is going on.
First, hdparm does not report correctly with hyperthreading enabled just as with the original machine. However, the problem is limited to the winchester drive, 3 - 7 MB/s reported read speed, the USB flash drive reports correctly ~30MB/s read timings.
Second, the problem shifts following a suspend/resume cycle. The winchester drive then reports ~150MB/s, but the USB flash drive reports ~20MB/s.
Third, the hdparm numbers aren't super accurate (well for USB actually pretty accurate) but they correlate to actual read bandwidth. Immediately following boot, USB 680MB 21.5s, winchester 710MB 11.297s. Following suspend/resume, USB 680MB 26.058s, winchester 710MB 5.206s. Caches purged of course and these numbers are repeatable.
Fourth, with hyperthreading disabled, hdparm and actual read speeds are as expected, USB 30+MB/s, winchester 120-150MB/s, always.
Fifth, boot time to ethernet up with hyperthreading enabled, ~17s, disabled ~27s.
Sixth, a CPU bound threading benchmark, sysbench, shows that hyperthreading is accomplishing something, with performance consistent across suspend/resume cycles.
Therefore, I'm sort of leaning against a board specific problem and more toward a design specific problem. Also, this problem is tenuous enough to be present in other Intel products but heretofore unnoticed. 

All experiments with 3.12 kernel.


On 5/14/2014 4:05 PM, Henrique de Moraes Holschuh wrote:

On Wed, 14 May 2014, Paul Ausbeck wrote:

While examining the kernel log for another reason, I came across
evidence that acpi_idle, and not intel_idle, is being used on my
dn2800mt system, see below. In fact, it seems that intel_idle cannot
be used. Is there some sort of binary blob involved here?

Well, I just did a quick hunting for when support was added...

commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Sat Jan 25 22:24:22 2014 +0100

     intel_idle: Add CPU model 54 (Atom N2000 series)
Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support 
     for this, detailed information about potential quirks or limitations are
     missing, though. So we just reuse the definition for the previous ATOM
     series. Tests on N2800 systems showed that this addition is fine an can
     reduce power consumption by about 0.25 W (personally confirmed on Intel
     DN2800MT).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> 
     Signed-off-by: Len Brown <len.brown@intel.com>


The bad news is that this commit is present only on kernel 3.15-rc.

It should be trivial to backport it to older kernels (it really just adds a
single line to the table of supported processors), but I didn't check if the
atom code in intel-idle received any fixes lately.

It might be worthwhile to test it, or to test the latest development 3.15
kernel (get it directly from Linus' git tree).  If you're going to test
3.15, do be aware that there's always increased risk of issues when testing
a non-released kernel, so the risks and the procedures I gave you for safe
testing of bissected kernels DO apply.

BTW, it is actually weird that acpi-idle would malfunction _or_ interact
badly with firmware, as it usually the more tested and stable idle driver
since it operates more closely to that other OS does than intel-idle :-)


Hmm, come to think of it, here's something you can try:

http://biosbits.org/

It is an official Intel testsuite for the BIOS/EFI.  And I *believe* you can
actually get it to boot Debian with replacement firmware it provides (my
best guess is that it overrides acpi tables and reprograms the processor and
chipset).
Reply to: