Hi,
we have made some performance tests on a PPC405 board.
First I can confirm “Kernel Benchmark Results” from QSSL.
You can get this performance results, if you get no TLB misses!
The problem on the ppc405 begins, if the normal work cycle of your
system uses much more than 64 4K-Pages. In this case your system uses
more an more time in the TLB-Miss exception and slows down dramatically.
A simple hack, if you have enough memory, to get more performance would
be the use of bigger pages.
Is the neutrino code PAGESIZE clean?
Would it be possible to setup a QNX System using a bigger page size (On
our ppc405 system perhaps 16k) ?
Well, years ago QSSL anounced 4 different memory protection models:
-
No protection, single address space, no process manager, everything
is linked with the micro kernel, virt. addr = phys. addr…
-
No protection, single address space, process manager, virt. addr =
phys. addr…
-
Full protection, single address space, process manager, virt. addr =
phys. addr…
-
Full protection, multiple address spaces, process manager, virt. addr
!= phys. addr…
At the moment, we have only model 4.
I think others have asked before, but I try again:
Are there any plans to implement one of the above models 1…3 in the
future?
E.g. on a booke cpu(e.g. PPC440) you could reduce the influence of the
MMU on the realtime performance to a minimum by using memory model 3
with variable sized tlb’s.
You would have full protection and only loose the fork API.
Kind regards
Michael
I think they do use large pages at least on some kernel versions. Not sure
about PPC.
You can probably forget about those other memory models.
“Michael Tasche” <michael.tasche@esd-electronics.com> wrote in message
news:9b77l4-3m5.ln1@comm.esd…
Hi,
we have made some performance tests on a PPC405 board.
First I can confirm “Kernel Benchmark Results” from QSSL.
You can get this performance results, if you get no TLB misses!
The problem on the ppc405 begins, if the normal work cycle of your system
uses much more than 64 4K-Pages. In this case your system uses more an
more time in the TLB-Miss exception and slows down dramatically.
A simple hack, if you have enough memory, to get more performance would be
the use of bigger pages.
Is the neutrino code PAGESIZE clean?
Would it be possible to setup a QNX System using a bigger page size (On
our ppc405 system perhaps 16k) ?
Well, years ago QSSL anounced 4 different memory protection models:
-
No protection, single address space, no process manager, everything is
linked with the micro kernel, virt. addr = phys. addr…
-
No protection, single address space, process manager, virt. addr =
phys. addr…
-
Full protection, single address space, process manager, virt. addr =
phys. addr…
-
Full protection, multiple address spaces, process manager, virt. addr
!= phys. addr…
At the moment, we have only model 4.
I think others have asked before, but I try again:
Are there any plans to implement one of the above models 1…3 in the
future?
E.g. on a booke cpu(e.g. PPC440) you could reduce the influence of the MMU
on the realtime performance to a minimum by using memory model 3 with
variable sized tlb’s.
You would have full protection and only loose the fork API.
Kind regards
Michael
For the PPC440, Large Page Support will be implemented in 6.4, but this will
not be a new memory model.
“Michael Tasche” <michael.tasche@esd-electronics.com> schrieb im Newsbeitrag
news:9b77l4-3m5.ln1@comm.esd…
Hi,
we have made some performance tests on a PPC405 board.
First I can confirm “Kernel Benchmark Results” from QSSL.
You can get this performance results, if you get no TLB misses!
The problem on the ppc405 begins, if the normal work cycle of your
system uses much more than 64 4K-Pages. In this case your system uses
more an more time in the TLB-Miss exception and slows down dramatically.
A simple hack, if you have enough memory, to get more performance would
be the use of bigger pages.
Is the neutrino code PAGESIZE clean?
Would it be possible to setup a QNX System using a bigger page size (On
our ppc405 system perhaps 16k) ?
Well, years ago QSSL anounced 4 different memory protection models:
-
No protection, single address space, no process manager, everything
is linked with the micro kernel, virt. addr = phys. addr…
-
No protection, single address space, process manager, virt. addr =
phys. addr…
-
Full protection, single address space, process manager, virt. addr =
phys. addr…
-
Full protection, multiple address spaces, process manager, virt. addr
!= phys. addr…
At the moment, we have only model 4.
I think others have asked before, but I try again:
Are there any plans to implement one of the above models 1…3 in the
future?
E.g. on a booke cpu(e.g. PPC440) you could reduce the influence of the
MMU on the realtime performance to a minimum by using memory model 3
with variable sized tlb’s.
You would have full protection and only loose the fork API.
Kind regards
Michael