[uClinux-dev] Re: MMU trade-off

2009-03-30 Thread Thomas Häberle

First of all: Thanks for the quick, frequent, interesting and informative 
response!!

The numbers mentioned by the developer were a gut feeling and rough estimation, 
not derived by tests and measurements,
but because I had neither I also had no basis to disagree.

The CPUs in use are PowerPCs (MPC852  MPC8247) from the PowerQuicc II family 
with 8MB to 32MB of RAM,
thus AFAIK the cache design is descent and the cache has not to be flushed 
completly on a context switch, right?

I'll take your information into account, propose some tests and let you know if 
we get proper results!

Thanks again and best regards,
Thomas


___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] Re: MMU trade-off

2009-03-30 Thread David McCullough

Jivin Thomas Häberle lays it down ...
 
 First of all: Thanks for the quick, frequent, interesting and informative 
 response!!
 
 The numbers mentioned by the developer were a gut feeling and rough 
 estimation, not derived by tests and measurements,
 but because I had neither I also had no basis to disagree.
 
 The CPUs in use are PowerPCs (MPC852  MPC8247) from the PowerQuicc II family 
 with 8MB to 32MB of RAM,
 thus AFAIK the cache design is descent and the cache has not to be flushed 
 completly on a context switch, right?
 
 I'll take your information into account, propose some tests and let you know 
 if we get proper results!

I think it might have been posted in one of the threads,  but just in
case it wasn't, here is a doc that gives numbers to MMU vs. no MMU.

http://opensrc.sec.samsung.com/document.html

Always good to have some real numbers ;-)

Cheers,
Davidm

-- 
David McCullough,  david_mccullo...@securecomputing.com,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.comhttp://www.uCdot.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


Re: [uClinux-dev] Re: MMU trade-off

2009-03-30 Thread Lennart Sorensen
On Mon, Mar 30, 2009 at 08:10:12PM +1000, David McCullough wrote:
 
 Jivin Thomas H?berle lays it down ...
  
  First of all: Thanks for the quick, frequent, interesting and informative 
  response!!
  
  The numbers mentioned by the developer were a gut feeling and rough 
  estimation, not derived by tests and measurements,
  but because I had neither I also had no basis to disagree.
  
  The CPUs in use are PowerPCs (MPC852  MPC8247) from the PowerQuicc II 
  family with 8MB to 32MB of RAM,
  thus AFAIK the cache design is descent and the cache has not to be 
  flushed completly on a context switch, right?
  
  I'll take your information into account, propose some tests and let you 
  know if we get proper results!
 
 I think it might have been posted in one of the threads,  but just in
 case it wasn't, here is a doc that gives numbers to MMU vs. no MMU.
 
   http://opensrc.sec.samsung.com/document.html
 
 Always good to have some real numbers ;-)

Well that's arm.  The arm always did seem to have one of the weirdest
memory setups.  It is the only cpu I have worked with where the OS ran
in virtual addresses compared to hardware.  Interesting to debug PCI
drivers when the addresses the hardware sees and the addresses the OS
sees don't match, but have to be mapped through some part of the MMU.

The PowerPC seems very straight forward and sane compared to the arm.
I hightly doubt the MMU has any significant impact on performance on
an PowerPC.  I have never tried running a PowerPC without the MMU though,
so I have no idea.  It runs very will with MMU on plain linux though.

-- 
Len Sorensen
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev