Re: hdparm -t yields incorrect timings when Intel hyperthreading is enabled
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).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: