[uClinux-dev] Re: MMU vs non MMU

Greg Ungerer gerg at snapgear.com
Wed Sep 10 01:51:01 EDT 2003


Hi Hyok,

Hyok S. Choi wrote:
>>>  CPU intensive code like calibrating routine, (i.e. bogo mips in arm
>>>kernel) made "the same result" on both kernel. (about 100.98 bogo
> 
> MIPS)
> 
>>>It is natural. The CPU activities on the intensive codes
> 
> 
>>Off-course.   <-- did you mean certainly? ^^

No, off-course. I would not expect any result other than the
bogomips being the same.


> So, Why did you concerned drystone for benchmark?
> Do you think it is much different with the calibrating routine?

Because you can run dhrystone as an application. It is not
ideal, it is a little small. But at least you have a close
workload to normal applications. Not a few lines of kernel code.

I would rather see something a little bigger, mp3 decode or
something like that. Or maybe even something silly like
allocate a couple of MB of RAM and work through it.


>>There is extra costs associated with maintaining the VM
>>system, more expensive process switches, TLB misses, etc. This is
>>what I would like to see measurements on. I don't expect the
> 
> difference
> 
>>to be large... but it needs to be measured so we know for sure.
> 
> 
> Hmm, it depends on what processes are working simultaneously. Isn't it?
> ^^ And the extra costs much depend on the architecture. And it is quite
> few, that is why MMU coprocessor exists.

I don't really understand what you are saying here. You are still
crossing into the kernel for a system call, and every hardware
interrupt (at least 100 a second for the jiffie timer). You can
still get TLB misses if you code is large enough (this will depend
on page size and TLB size).


> And I can figure out that you think uClinux must be faster than
> conventional Linux kernel.

I have read at least one set of documentation from a silicon
vendor that listed a 2-4% performance degradation when using
the MMU/VM system on typical work loads compared to no-MMU.

You haven't presented any numbers yet that make me think this
is wrong...


> Please teach me, why the kernel initialize
> code in uClinux takes much longer time than linux kernel? (especially
> "mem_init")

I don't know, you have the fancy tools to measure these things :-)


> So, why your company didn't measure the performance difference between
> uClinux and linux? Companies like snapgear would need the difference
> result data.

Not at all. The company I work for does not make silicon. I cannot
chose to put an MMU on a processor that doesn't have one. I just
have to code the software to make it work in a product either way.

There is very little point me measuring difference between
having an MMU and not if the CPU I am using doesn't have one.

If I have a CPU with an MMU I will be using it, I am willing
to take a couple of % performance impact because of all the nice
features I will get (way less memory fragmentation problems,
real fork, dynamic stacks, etc, etc).


>  Manufacturer like Samsung we concern only cost, time to
> market, and so on. As you know, our applications are very specific. ^^

Really. And you think any other company in this industry is any different?

Cost is everything.


> Anyway, my hacked Linux kernel code reaches cpu_idle call in 71msec from
> head, for s3c2410, and hacked uClinux in 151msec, even though it has
> large 64MB ram and several device drivers include console. It is just
> good for me.

Are you really comparing the same things?
Are the too identical except for one has MMU enable and the other not?

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude          EMAIL:  gerg at snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com



More information about the uClinux-dev mailing list