[meta-ti] poor performance of OpenEmbedded on, BeagleBoneBlack compared to Debian

[Khem Raj]

On Thu, Sep 4, 2014 at 8:55 AM, Peter A. Bigot <pab at pabigot.com> wrote:
> 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 at pabigot.com> wrote:
>>>>>
>>>>>> One anomaly I've found is the CPU frequency range.  On debian we have:
>>>>>>
>>>>>>     debian at beaglebone:~$ cat
>>>>>> /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
>>>>>>     300000 600000 800000 1000000
>>>>>>
>>>>>> while on OE we have:
>>>>>>
>>>>>>     root at 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.
>

can you profile run it.? As i understand, you have exact same hardware
and same way of running
it with two different rootfs.

>
>>
>>> 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
>
> --
> _______________________________________________
> meta-ti mailing list
> meta-ti at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti