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

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

Henrique, thanks a lot for the detailed reply. I will look at the stuff that you suggested, if only to learn about what I don't know.
FYI, the problem doesn't seem related to temperature to me. I'm not ruling it out, I'm just saying it doesn't have that feel.
I look at it like this. hdparm says that disk bandwidth is much lower than it should be, but only when hyperthreading is enabled. But, the system doesn't appear to be THAT much more unresponsive when hyperthreading is enabled over when disabled. So I'm leaning toward the idea that hdparm's calculation is being spoofed somehow. We have bytes/time so either bytes is smaller, or time is larger than an accurate value. Likely, though, the two variables are somewhat conflated. Let's say that hdparm thinks its transferring bytes for '2' seconds, but in reality the system is blocking somewhere and the full '2' seconds is not actually being used. In order to explain the similar responsiveness in actual use, my first guess would be that whenever, say thread 'hdparm' is blocked, another thread, say 'anythingelse' is run instead.
I will put this issue in the queue and will work consistently on it as a background task. Forensically, I think the first thing I'll verify is the Timex time between the visual appearance on the display of the various hdparm strings. It's hard to see how the system could be so fooled that watch time is off, but experience begets comfort.
Lastly, the difference in boot times may not be due to the hyperthreading issue, at least directly. There are quite a few differences in the kernel log (errors, warnings) between the various versions. So I'll have to spend some time at some point to pin down what these log messages actually mean. 

On 5/9/2014 12:30 PM, Henrique de Moraes Holschuh wrote:

On Thu, 08 May 2014, Paul Ausbeck wrote:

Next, I don't agree that this hyperthreading problem reeks of a
firmware issue. What it reeks of is a linux kernel issue. I'm not

Well, it reeks of bad interaction of Linux and the firmware, which *usually*
is caused by bad firmware when an Intel desktop motherboard is involved, and
very often fixed by newer firmware.


Next, both recommending a firmware update and asking for
/proc/cpuinfo were red herrings reminiscent of a conversation with
any modern corporate support department. I will state flatly, that

*I* asked for cpuinfo because I wanted to know the as-seen-by-the-kernel
processor topology, as it is very important for correct operation of the
SMP/SMT-aware process scheduler.

I also wanted to know the microcode revison level (available in cpuinfo)
because Intel did something funny with microcode updates for your processor
in the past and I wanted to know if you had a version earlier than version
0x106.


that and starting anew with open source. Please give me at least
token respect. It's just plain fact that Windows 7 gives one
confidence that hyperthreading is functioning properly and linux
doesn't

Linux Linux interacts very differently with the ACPI and EFI firmware and
the low-level hardware (including the processor itself, the interrupt
controllers and the memory controllers, the PCIe bridges, the IOMMU...) when
compared to Windows 7.


Next, from just this one data point, my experience tells me that
linux isn't exactly playing friendly with Intel hyperthreading.
Given that Intel is not that interested in hyperthreading any more,

A single datapoint is indeed not enough.  Hyperthreading on Intel Core
related microarchs works very well for most workloads, to the point that
even the newest Xeon E3v3, E5v2 and E7v2 families have hyperthread-enabled
cores on most of the processors.  The same goes for most of the Core i5/i7
desktop parts.  Intel seems to be still quite interested in HT.

It is entirely possible that hyperthreading on Atom does not work nearly as
well as in the Core/Xeon as far as I know -- I don't have direct experience
with Atom processors -- but a quick google search tells me people usually
find HT on Atom to be a performance advantage, though.


Next, I don't get what I'm supposed to bisect. Every kernel I've
tried, 3.2.0-4, 3.12-0, and 3.12.9 have obvious issues with
hyperthreading. So it seems unlikely to me that any kernel would
function properly. In order to bisect, the first step is to find a
correct kernel. Perhaps someone could recommend one.

Well, I misunderstood you.  I thought there was at least ONE kernel that
worked with HT enabled.  Indeed, if there is no kernel that works well with
HT on your board, bissection is impossible.


Next, it's not the case that I was confused. hdparm is still a
reliable canary for hyperthreading problems on the dn2800mt
motherboard. See attached data below, kernel 3.2.0-4 only . When

I agreed with you that hdparm is a very good way to reproduce the problem
("canary").


But since my hyperthreading issue has not been trivially resolved on
this list, I'm sort of assured that I'm not missing that trivial
something. If after a few more days I still don't have a trivial
answer, I will file a kernel bug.

One thing comes to mind.  Try switching the low-level kernel idle-loop
driver.  There are at least two that should work with your processor:
acpi_idle, and intel_idle.  Usually, intel_idle will be prefered.  Disable
it (compile a kernel with just ACPI idle, or if it is a module, blacklist
it).  The acpi-idle driver does things a lot closer than what windows 7
does.  Do keep an eye on processor temperature while doing this test.

Other stuff that might show up clues on what is wrong by direct comparison
between HT-enabled and HT-disabled:

/proc/interrupts (interrupt routing and TLB flush behaviour).
/var/log/dmesg
output of lspci -vvv *as root*.

Compare them in the HT-disabled and HT-enabled states.

If it works on your processor, check whether "powertop" shows something
remarkably different in the processor behaviour re. frequency and idle
states when you run with HT enabled, and HT disabled.  Do this with hdparm
running, of course.   Alternatively, try it using the "turbostat" utility
you can find in the tools/power/x86/turbostat directory inside the kernel
source tree (use the turbostat from 3.12 or 3.13 regardless of kernel
version).
Reply to: