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

[Paul Ausbeck <paula@soe.ucsc.edu>]

I've actually done dummy file reads and writes previously. Well actually just writes. And they go at full speed, no matter what hparm says. For example, your example, works at full speed:

dd if=/dev/zero of=somefile bs=10M count=100 ;

I've tried the analogous read:

dd of=/dev/null if=somefile bs=10M count=100 ;

but I wasn't able to find a way to purge the disk cache before I got sidetracked. Perhaps you know of a magic incantation  for that?

Also, if you look at my data again, you'll see that hdparm -T is not affected by the hyperthreading state, it's only hdparm -t that's affected.

On 5/9/2014 2:56 PM, Henrique de Moraes Holschuh wrote:

On Fri, 09 May 2014, Paul Ausbeck wrote:

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.

What I mean is that when you mess with the low-level idle loop driver, it is
not impossible to get all cores and hardware threads of the CPU stuck at C0
state (i.e.  running 100% of the time).  This *shoudln't* happen, but still
it is best that you are aware of the possibility that you might end up
testing the cpu heatsink/cooler as well...

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.

Hmm, there's a way to test.  Time how much wall-clock time it takes to write
a large file to disk and sync (flush to disk) the result, preferably in
single-user mode:

sync; date ; dd if=/dev/zero of=somefile bs=10M count=100 ; sync; date

That should do it (the above creates an 1GiB file).  It will also test the
scheduler, as that /dev/zero read does cause syscalls and switches to kernel
context.

BTW, the output of "hdparm -T" should not vary an order of magnitude.  If it
does and there is nothing obnoxious running in the background, you've got
closer to the problem.  I doubt it is something like this, though: your
system would be sluggish as all heck...

Lastly, the difference in boot times may not be due to the
hyperthreading issue, at least directly. There are quite a few

Indeed.  However, when looking at the timings in the /var/log/dmesg
comparison, remember the comparison is less for the timings, and more for
everything else.  Note that some reordering across boots, even of the same
kernel, is perfectly normal.