Re: poor performance of OpenEmbedded on, BeagleBoneBlack compared to Debian

["Peter A. Bigot" <pab@pabigot.com>]

On 09/04/2014 10:48 AM, Denys Dmytriyenko wrote:
> On Thu, Sep 04, 2014 at 10:37:24AM -0500, Peter A. Bigot wrote:
>> On 09/04/2014 10:00 AM, Denys Dmytriyenko wrote:
>>> On Thu, Sep 04, 2014 at 02:50:03PM +0000, Mikhail Zakharov wrote:
>>>> On Wed, Sep 3, 2014 at 8:59 PM, Peter A. Bigot <pab@pabigot.com> wrote:
>>>>
>>>>> One anomaly I've found is the CPU frequency range.  On debian we have:
>>>>>
>>>>>     debian@beaglebone:~$ cat
>>>>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
>>>>>     300000 600000 800000 1000000
>>>>>
>>>>> while on OE we have:
>>>>>
>>>>>     root@beaglebone:~# cat
>>>>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
>>>>>     300000 600000 720000 800000
>>>> Stock yocto-bsp is missing a few things that can be found in Robert
>>>> Nelson's patchset for 3.14 linux kernel.
>>>>
>>>> There are lots of other functionality that is missing from yocto-bsp
>>>> kernel for Beaglebone. I suggest you take at the following repos and
>>>> scavenge for what you need :P
>>> First of all, this is meta-ti mailing list for the corresponding BSP. That's
>>> what Peter was asking for, comparing to Robert's Debian and Yocto reference
>>> BSPs, not the other way around.
>>>
>>> Second, Yocto reference BSP is that way for a reason - it's a reference BSP
>>> done with pure mainline kernel and u-boot components w/o any patching on top.
>>> That's its entire purpose. For anything else special, including performance
>>> tweaks, there are other BSPs available. If there is an issue with performance
>>> in meta-ti, we'll investigate it and try to match with Robert's BSP.
>> Yes, at this time meta-ti's BSP performs as well as I've seen any
>> OE-based system, and gets several things right that meta-yocto-bsp
>> does not (and one thing wrong that meta-yocto-bsp gets right, I
>> think; still investigating, will follow-up when I'm sure).
>>
>> I've also verified that performance with a native gcc 4.9.1 build on
>> BeagleBone with hard float is poor, so it's not due to the way OE
>> builds gcc.  I have several competing hypotheses to test.
> Can you please point to the test case you were using to measure time? I'd like
> to try it with few different toolchains here as well. BTW, we are currently
> using Linaro gcc-4.7.3 - I'm wondering how it performs.


The context is: 
http://scruss.com/blog/2013/09/23/beaglebone-black-slow-as-a-dog/

The specific application is: http://www.cs.utah.edu/~aek/code/card.cpp

The "ought to work" compiler line is: g++ -Ofast card.cpp -o card

The "kitchen-sink-still-doesn't-help" compiler line is:

g++ \
   -march=armv7-a -mtune=cortex-a8 \
   -mthumb-interwork \
   -mfloat-abi=hard -mfpu=neon \
   -Ofast \
   -o card \
   card.cpp

All my tests are with gcc-4.9.1, with or without the openembedded-core 
patch set.

>
>> But I'm still looking for a way to set the CPU frequency to the
>> higher values supported on Beaglebone Black.  I had hoped meta-ti's
>> would be able to do that, since it has bone vs boneblack device
>> trees and u-boot detection.
>>
>> Any hints where to look for clock settings?
> Some of those values are considered overclocking and according to the manual
> will reduce the lifespan of the part...

So the Beagle Bone Black SRM's claim that the AM3358BZCZ100 can run at 
1GHz is not entirely true?  Or is it just that the operating-points in 
that patch are too aggressive?

Peter