Re: PAE or not PAE?
Gene Heskett <gheskett@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.
Reply to: