Gene Heskett <ghesk...@shentel.net> writes: > On Monday 12 March 2018 15:27:23 Hans wrote: > >> > Note that the non PAE kernel in older Debian versions up to Jessie >> > lacked multi-processor (including multi-core and hyper-threading) >> > support. >> >> Yes, I read this, too. The N280 is a single core, but mith >> hyperthreading, I have two cores. >> >> Is this still so, that the non-pae-kernel lacks still hyperthreading, >> or does it do today, too? >> >> And second question: Is PAE preferred (with the look to speed) or >> better use non-pae? >> >> Cheers >> >> Hans > > Both pae and hyperthreading take time, hyperthreading quite a bit more > than pae. With hyperthreading, to switch to the 2nd task, takes a > complete processor state stored on the stack, the stack pointer reloaded > to point at the image of the 2nd task, then pull the full register dump > for task 2 back into the processor. Then and only then can the first > cycle devoted to task 2 be initiated. Ditto to swap back. For boxes that > will run a realtime task, the first thing we do is turn off the > hyperthreading. Its a solution that works ok, but I can't think of a > better way to make a decently fast cpu into a provable slowpoke. All it > really does for us is to help heat the shop. You can keep it above the > dew point with electric heat to help control rust, or you can enable > hyperthreading and its exactly the same turns of the electric meter > either way. An excellent demo of the TANSTAAFL principle.
This doesn't correlate with my understanding of the process. My understanding, and every block diagram I've seen of a processor capable of hyperthreading, has a separate set of architectural registers for every thread. The processor does need to start refilling the pipeline on a thread switch, but doesn't do any register dump. I will agree that it increases the unpredictability of execution time, and if I wanted to guarantee I could meet deadlines I'd turn it off.