> If you are using a hyper-threading and there is an interrupt or a system call on one logical core, then the hyper-sibling will stall as well because both need access to the kernel (mode switch).
This is kind of correct. That is, for cases where the kernel implements microarchitectural data sampling mitigations (think spectre). Almost all low latency shops run their apps with SMT disabled so this does not apply but when using HT and with mitigations enabled the kernel has to synchronize ring 0 transitions. Se more here: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/intel-analysis-microarchitectural-data-sampling.html On Sat, Jul 2, 2022 at 7:16 AM peter royal <[email protected]> wrote: > is it possible the book was accurate at the time of writing but hardware > has since improved? > -pete > > -- > (peter.royal|osi)@pobox.com - http://fotap.org/~osi > > On Jul 1, 2022, at 8:54 PM, Peter Veentjer <[email protected]> wrote: > > > Hi, > > I'm reading the following book "Developing High-Frequency Trading > Systems". My goal is not to write any high-frequency trading systems, but > to get some insights into the domain and learn as much as possible from the > applied techniques. It is a Packt book and they are not known for their > quality. But it is written by 3 engineers with a combined HFT experience of > almost 50 years. > > On page 62 of the book, they make the following claim. If you are using a > hyper-threading and there is an interrupt or a system call on one logical > core, then the hyper-sibling will stall as well because both need access to > the kernel (mode switch). > > I don't believe this is correct. Each logical core has its own > architectural state; so its own set of architectural registers and its own > APIC including an interrupt descriptor table. The current privilege level > is stored in the first 2 bits of the CS register and since every logical > core has its own copy of that, the hyper siblings should be able to run > independently no matter if there is a mode switch. > > Of course, disabling hyper-threading will lead to improved performance of > a single core, because it doesn't need to share any resources like rob, > line fill buffers, store buffers, load buffets, execution units, > reservation stations, caches, etc. So that is a valid reason to disable > hyper-threading. > > I'm by no means an X86 expert and certainly not a high-frequency trading > expert. So perhaps I'm missing something. > > Regards, > > Peter. > > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdChA2kzo1RXHUB3Zh1H5GonVs82BhkCzG7ap4Q1PaUvdg%40mail.gmail.com > <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdChA2kzo1RXHUB3Zh1H5GonVs82BhkCzG7ap4Q1PaUvdg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/473A9790-D9B6-46DA-8C8C-8FD98957EB76%40pobox.com > <https://groups.google.com/d/msgid/mechanical-sympathy/473A9790-D9B6-46DA-8C8C-8FD98957EB76%40pobox.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAHNMKAqzLGqRmuZThB9YrFaAiAgx-4zSxjFiwbRnFkyQu-Hn3w%40mail.gmail.com.
