Web lists-archives.com

Re: PAE or not PAE?




Gene Heskett <gheskett@xxxxxxxxxxx> 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.