Re: PAE or not PAE?

[Henrique de Moraes Holschuh]

On Mon, 12 Mar 2018, Neo wrote:
> No PAE.
> 
> For 2GB of RAM it makes no sense. You just need this on 32bit machines with
> more than 4GB of RAM.

You need PAE to get the NX (non-execute) protection, and also KPTI (aka
Meltdown defense).  Note that KPTI for i686 is a work in progress.

So, it might make sense to run PAE kernels even on 2GiB RAM, it depends
on whether you consider NX important or not (and KPTI in the future).

-- 
  Henrique Holschuh

Re: PAE or not PAE?

[Pascal Hambourg]

Le 13/03/2018 à 04:57, Joe Pfeiffer a écrit :

Gene Heskett  writes:


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.


What you describe is software multi-threading/multi-tasking, not 
hyperthreading.



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.


I agree.


The processor does need to start refilling the pipeline
on a thread switch


I don't think so, because IIUC there is not thread switch. Both threads 
instructions can be executed in parallel as long as they do not use the 
same resource.



I will agree that it increases the unpredictability of execution time,


This is the endless trade-off between thoughput and response time.

Re: PAE or not PAE?

[Stefan Monnier]

> 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.

Turning it off may indeed improve predictability of execution time in
some cases.  Especially if the various active threads have different
real-time priorities.

For non-real-time threads, turning it off would just replace the
hardware's scheduler unpredictability with that of the OS.

For really hard real-time, of course, you still have many other sources
of unpredictability: the cache(s), the TLB, the branch prediction, ...


Stefan

Re: PAE or not PAE?

[Joe Pfeiffer]

Gene Heskett  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.

Re: PAE or not PAE?

[Gene Heskett]

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.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: PAE or not PAE?

[Pascal Hambourg]

Le 12/03/2018 à 20:27, Hans a écrit :

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?


"Today" does not tell much. It depends what Debian version you have.
Since Stretch, the non PAE kernel supports multiprocessing.


And second question: Is PAE preferred (with the look to speed) or better use
non-pae?


PAE does not make the kernel faster. On the contrary, as it adds an 
extra indirection when accessing memory.

Re: PAE or not PAE?

[Neo]

Am 12.03.2018 um 20:04 schrieb Pascal Hambourg:


No, you also need it on machines with 4 GiB of RAM and remapping 
capability, in order to use the part of the RAM which is remapped 
beyond the 4-GiB boundary due to the "PCI hole". Usually the remapped 
memory amount is about 500 MB, but I have seen machines remapping 1 
GiB or even 2 GiB, leaving only 2 or 3 GiB of usable RAM with a non 
PAE kernel.


Note that the non PAE kernel in older Debian versions up to Jessie 
lacked multi-processor (including multi-core and hyper-threading) 
support.




Thx for the clarification.

Re: PAE or not PAE?

[Pascal Hambourg]

Le 12/03/2018 à 20:04, Pascal Hambourg a écrit :

Le 12/03/2018 à 12:31, Neo a écrit :


You just need this on 32bit machines with more than 4GB of RAM.


No, you also need it on machines with 4 GiB of RAM and remapping 
capability, in order to use the part of the RAM which is remapped beyond 
the 4-GiB boundary due to the "PCI hole". Usually the remapped memory 
amount is about 500 MB, but I have seen machines remapping 1 GiB or even 
2 GiB, leaving only 2 or 3 GiB of usable RAM with a non PAE kernel.


Note that the non PAE kernel in older Debian versions up to Jessie 
lacked multi-processor (including multi-core and hyper-threading) support.


I forgot to mention that the NX/XD bit used by the "execute disable" 
protection against execution of data pages is available only with PAE.

Re: PAE or not PAE?

[Hans]

> 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

Re: PAE or not PAE?

[Pascal Hambourg]

Le 12/03/2018 à 12:31, Neo a écrit :

No PAE.

For 2GB of RAM it makes no sense.


Indeed.


You just need this on 32bit machines with more than 4GB of RAM.


No, you also need it on machines with 4 GiB of RAM and remapping 
capability, in order to use the part of the RAM which is remapped beyond 
the 4-GiB boundary due to the "PCI hole". Usually the remapped memory 
amount is about 500 MB, but I have seen machines remapping 1 GiB or even 
2 GiB, leaving only 2 or 3 GiB of usable RAM with a non PAE kernel.


Note that the non PAE kernel in older Debian versions up to Jessie 
lacked multi-processor (including multi-core and hyper-threading) support.

Re: PAE or not PAE?

[Neo]

No PAE.

For 2GB of RAM it makes no sense. You just need this on 32bit machines 
with more than 4GB of RAM.


HTH

Tom


Am 12.03.2018 um 12:11 schrieb Hans:


Hi folks,

as I have still trouble with restore after suspend-to-disk, I read, 
that this issue was gone with a kernel with non pae.


This brings the following question:

MUST I use (or is it RECOMMENDED?) a kernel with PAE in my system?

My system:

CPU N280 (with PAE usable)

2 GB RAM

32-Bit operating system (debian/testing)

Do I have any advantages or disadvantages by using a PAE-Kernel or 
NON-PAE-kernel? I will never be able to use more than 2 GB RAM, as 
this EEEPC got only one RAM slot (I never saw a single DDR2 4 GB 
RAM-module, just 2 GB).


Thanks for the hint.

Best

Hans

P.S. For Gene Haskett: I tried a NON-PAE kernel on my EEEPC - did not 
boot (just an idea)