[Beowulf] Hyperthreading and 'OS jitter'

[Scott Atchley]

I would imagine the answer is "It depends". If the application uses the
per-CPU caches effectively, then performance may drop when HT shares the
cache between the two processes.

We are looking at reserving a couple of cores per node on Summit to run
system daemons if the use requests. If the user can effectively use the
GPUs, the CPUs should be idle much of the time anyway. We will see.

I like you idea of a low power core to run OS tasks.

On Sat, Jul 22, 2017 at 6:11 AM, John Hearns via Beowulf <
beowulf at beowulf.org> wrote:

> Several times in the past I have jokingly asked if there shoudl eb another
> lower powered CPU core ina  system to run OS tasks (hello Intel - are you
> listening?)
> Also int he past there was advice to get best possible throughpur on AMD
> Bulldozer CPUs to run only on every second core (as they share FPUs).
> When I managed a large NUMA system we used cpusets, and the OS ran in a
> smal l'boot cpuset' which was physically near the OS disks and IO cards.
>
> I had a thought about hyperthreading though. A few months ago we did a
> quick study with Blener rendering, and got 30% more througput with HT
> switched on. Also someone who I am workign with now would liek to assess
> the effect on their codes of HT on/HT off.
> I kow that HT has nromally not had any advantages with HPC type codes - as
> the core should be 100% flat out.
>
> I am thinking though - what woud be the effect of enabling HT, and usign a
> cgroup to constrain user codes to run on all the odd-numbered CPU cores,
> with the OS tasks on the even numbered ones?
> I would hope this would be at least performance neutral? Your thoughts
> please! Also thoughts on candidate benchmark programs to test this idea.
>
>
> John Hearns........
>  ....... John Hearns
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20170722/24da832d/attachment.html>