• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 687 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L137 Performance

Martin Pavier
Prodigy 30 points
Other Parts Discussed in Thread: OMAP-L137

I'm running Linux 2.6.37-rc2 on an OMAP-L137 EVM board (Spectrum Digital).

When reproducing the lmbench test results published by Penguintronix (http://www.pengutronix.de/development/kernel/arm-benchmarks-20100729_en.html) our performance figures are quite poor when compared against the i.MX27 (Freescale) processor which is using the same ARM926EJ-S processor core.

The performance figures I get are as follows:

lat_ops (Floating point multiplication)

i.MX27 figure : 72.39ns, our figure 97.13ns

bw_mem (Memory transfer speed, reading and writing to same memory location)

i.MX27 figure : 101.3Mb/s, our figure 124.1MB/s

lat_ctx (Context switching time for 16 processes of 8kb size)

i.MX27 figure : 130.4us, our figure 261.29us

lat_syscall (Time taken to open and close a 1Mb file on tmpfs in RAM)

i.MX27 figure: 14.16us, our figure 54.67us

lat_proc (Time taken to create 2 identical processes and have one of them exit)

i.MX27 figure: 3135.6us, our figure 6165.3us

As can be seen in the figures our performance is significantly worse for context switch, system call and process fork/exit!

 

Has ANYONE seen performance issues with Linux on the OMAP-L137 processor?

Any ideas/suggestions?

Regards,

Martin. 

  • 0
    Prodigy 30 points

    Our application is an implementation of the can/nmea protocol at 250kb/s

    We decided quickly that our application could not run in userspace so we ported it to xenomai real time linux.

    Even there we found the overhead of interrupts and context switches was too much so we moved the application

    to the dsp and there it works ok.

    We have subsequently run eCos on a l138 with the same application and it seems to perform as we expect there.

    Our conclusion was that either there is a problem with mmu/virtual memory or cache, the first is not a problem with

    eCos because there is only one fixed virtual mapping, the second is not such a big problem with eCos because the

    amount of code in the eCos kernel is many times smaller than in the linux kernel.

    None of this explains why your iMX27 runs so much better, which has the same kernel, an arm926 and the same cache size

    as far as I can see (and the same linux kernel). There is probably some parameter which is not as obvious as cache

    size and cpu kernel which also has an influence on things.

    I looked at the SDRAM performance counters as part of my analysis and found that even on an idle system there was a lot

    of activity. Perhaps an indication of a bad cache implementation, but this is just a guess.

    I also looked at interrupt latency with a pulse generator connected to a gpio and found very bad performance.

    Linux died with only a few thousand interrupts per second.

     

    Good luck with your tests.

    /Brian

  • 0 in reply to Brian Murphy67318
    Prodigy 60 points

    Hi Martin,

    Can you please tell us how have you booted the latest 2.6.37 kernel on Spectrum's OMAP L137 EVM.

    I have successfully compiled the kernel but when i put it on board. It stops at

    Uncompressing Linux ..............................................

    Are there any patches to apply on the 2.6.37 kernel or just the kernel config file(.config) modification  is enough to boot it.

    thanks

  • 0 in reply to kalyan alle
    Prodigy 30 points

    Hi,

    The 2.6.37 kernel wasn't a plain vanilla kernel from kernel.org, it has been patched (it's full name was 2.7.37-rc2), If think we downloaded it from here: http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary

    As for kernel configuration I did the following:-

    make mrproper -> Wipe out all the configuration (full, clean setup)

    make davinci_all_defconfig -> Pickup default configuration

    make uImage -> Do the build.

    Also be careful to make sure your command line specifies ttyS2, include the following when launching "console=ttyS0,115200n8" (After the uncompressing Linux message the output swaps over to using the kernel's console driver so if the console isn't properly specified then it'll stop at that point).

    Hope this helps,

    Martin