Re: [LAU] i5 Hyper-Threading, BIOS settings and Arch n00b pointers

On Thu, 28 Aug 2014 23:40:01 +0000
Kaza Kore <dj_kaza@email-addr-hidden> wrote:

> So can anybody point to any conclusive evidence that i-series
> processors benefit from having HT disabled on a Linux based DAW?
> Preferably benchmarks on a system installed with HT Enabled and
> Disabled using a recent kernel and system.

I changed email address on this list about a week ago, and posted the
following msg, seems it's didn't get through so I'll send an improved
version :)

AFAIK there are 2 points to be considered.

1. SMT (at least as implemented on iX cpus) break the entire concept
of realtime. You do get an estimated increase in CPU throughput of
about 25%, at the possible cost of stealing CPU time (thus latency) from
your realtime threads. In effect a lower priority thread thread can
run on the sibling CPU (same core) stealing CPU time from your realtime
thread.

2. I suspect that the CPU cache is too small. and that SMT can also
cause cache depletion, which would explain some xruns I have seen while
torture testing the system doing real lowlatency audio and running
hackbench at the same time. Reloading the cache cam take significant
time.

Speedstep was already covered by someone else.

CPU management is a thorny question. That setting is probably
related to System Management Interrupts (SMIs), which can be very bad
indeed. Normally used for fan control and other functions by the
BIOS. The really bad thing is that they block execution and there is
nothing the kernel can do about it. if it's only for a few usecs,
it's probably not a problem, but if it's milliseconds, it is..

There is a program called hwlatdetect in the rt-tests package that can
be used to determine how big the problem is. It consists of a kernel
module and a python script to start it and to report the results back
to the user. What is it does is basically to stop all kernel execution
and then to loop reading TSC timestamps. If it finds breaks in the
data stream they will have been caused by SMIs.

-- 
   Joakim
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user