Hyper-threading under Linux

Stefan Praszalowicz stefan at avedya.com
Thu Dec 19 03:56:01 CST 2002


Adding more to the subject...

I think the 2.4.20-ac2 branch has Ingo Molnar's patches to avoid the
issue in 2)

More generally about processor cache, here's an interesting talk Alan
Cox gave for Umeet 2002 (an IRC based unix conference):

http://umeet.uninet.edu/umeet2002/talk/2002-12-14-linux1.txt.html

where he briefly mentions HT too.


On Thu, 2002-12-19 at 09:48, Steve_L_Smith at dell.com wrote:
> There have been a couple of threads on this topic lately, so I thought I'd
> add my perspective.
> 
> Hyper-threading is an attempt to maximise the usage of physical cpu
> resources, based on the assumption that many applications are not CPU bound,
> therefore they have spare resources available. By creating two virtual
> processors for every physical processor, and using some trickery to save
> architectural states for each process, you are often able to get better
> performance from a set of applications with HT enabled. This is generally
> true for applications such as databases where I/O is often the bottleneck;
> while one process is waiting for data, another process can utilise the cpu
> without the normal flushing required where hyperthreading is not enabled.
> However, for CPU intensive applications (esp. scientific and technical
> codes) this is not the case, the CPU is already heavily loaded and all
> hyperthreading does is add overhead.
> 
> Some things to note:
> 1) with HT on, you share the cache of a single physical processor between
> two virtual processors, so the likelihood is that your cache miss rate will
> rise
> 
> 2) the Linux standard scheduler is not good at processor affinity, i.e.
> locking a process to a given processor and being aware that two virtual
> processors may actually be on one physical processor. Assume you have a dual
> processor system with HT on, and you run two processes. Process 1 may be
> assigned to virtual processor 1 which is on physical processor 1, and
> process 2 may be assigned to virtual processor 2 which is also on physical
> processor 1! Result - physical processor 2 is idle whereas physical
> processor 1 is heavily overloaded! HT really does require strong processor
> affinity to work well. There is a patch that provides a fully-HT aware
> scheduler, from Ingo Molnar
> 
> 3) Each virtual processor may consume a software licence for your
> application! If you have a 2-cpu licence for an application and run it on a
> system with 4 virtual processors, you might a) run out of licences, b) find
> your two processes fighting for resource on 1 physical processor, c) get
> half the performance you would get with HT off.
> 
> So no simple answer to whether it is good or not - depends on your apps and
> workload mix.
> 
> There are some articles on HT in the latest issue of Power Solutions -
> www.dell.com/powersolutions
> 
> 
> HTH
> 
> Steve
> -------------------------------------------------
> Steve Smith
> HPC Business Manager
> Dell EMEA
> Dell Campus, Cain Road, Bracknell, RG12 1FA, UK
> Direct: +44 1344 372037
> Switchboard: +44 1344 812000
> Fax: +44 1344 372359
> Mobile: +44 7802 594874
> email: steve_l_smith at dell.com
> ------------------------------------------------------
>  
> 
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq or search the list archives at http://lists.us.dell.com/htdig/
-- 
Stefan Praszalowicz <stefan at avedya.com>
Avedya




More information about the Linux-PowerEdge mailing list