Thanks Avi, that's interesting. I was under the impression that the Intel doc was referring to x86 specifically. I'm a bit confused about the discrepancy between what how that document describes the mitigation and your comment. Could you point to a resource or Kernel source file that sheds more light on this?
On Sun, 3 Jul 2022, 11:22 Avi Kivity, <[email protected]> wrote: > It's true for IBM POWER, where all of a core's threads have to be in > kernel mode or user mode and cannot intermix. > > > It's not true for x86. I also don't believe there is a stall during the > mode transition, otherwise a thread that continuously issues null system > calls could stall its sibling. That should be easy to test. > On 02/07/2022 06.54, Peter Veentjer 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/5e74f6e3-d0fe-452d-fa9e-146860767785%40scylladb.com > <https://groups.google.com/d/msgid/mechanical-sympathy/5e74f6e3-d0fe-452d-fa9e-146860767785%40scylladb.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/CAHNMKAq7ZcxV5PR%2Bqh4FWhnttcw5u9jL-Dvd-XRqTZdGYkNmSg%40mail.gmail.com.
