Not all applications can take advantage of hyperthreading, but they do exist. In our environment we leave hyperthreading on in the bios, but set the slot limit per node to the number of true cores, rather than the number of HT threads. Users with HT-capable apps can request n cores and run n*2 threads. There are multiple ways to limit the number of slots per node (and we may change the way we do it based on a recent thread). I would not want to have the number of slots count HT threads, as you are likely to overload the node on many applications. We enable binding to ensure jobs starting many threads don't get to spill over to more cores than they requested. By default on SoGE with -binding linear:slots, asking for n cores will get you all the "threads" on each of those cores. As an example, we have users ask for 4 cores with qsub -pe smp 4 and they get the 4 cores and all associated HT threads. If their application is one of the few that works well with HT, they can have their application run 8 threads. In a previous environment I've had a few dedicated nodes and a separate ht queue that had slots=ht count, but that does not work well if nodes will be running a mix of ht and non-ht jobs.
These are just my experiences and the way I've done things. YMMV, TMTOWTDI, etc. Best, Chris Ref: http://arc.liv.ac.uk/SGE/howto/sge-configs.html#_slot_limits_a_id_slotlimit _a On 3/15/16, 3:43 PM, "Lane, William" <william.l...@cshs.org> wrote: >I'm just curious about what the current thoughts are WRT hyperthreading. > >I've read at least one article that suggested hyperthreading be left on >so that >the OS can take advantage of it, but that hyperthreading cores should be >excluded >from being bound to SoGE HPC jobs. Is this still the best strategy to >follow? Or >was it ever a good strategy to follow? > >Could excluding hyperthreading cores be accomplished by using the qsub >-binding >parameter? Or should SoGE itself be configured to ignore hyperthreading >cores? > >My research into hyperthreaing and HPC has only turned up two strategies: >1. turn off hyperthreading completely at the BIOS level >2. the above situation where the OS is still allowed to use >hyperthreading but HPC >apps are disallowed binding to hyperthreading cores. > >Thank you in advance. > >-Bill L. This electronic message is intended for the use of the named recipient only, and may contain information that is confidential, privileged or protected from disclosure under applicable law. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, disclosure, dissemination, distribution, copying or use of the contents of this message including any of its attachments is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately by contacting the sender at the electronic mail address noted above, and destroy all copies of this message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email. _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
