Why won't my app use multiple threads under 'valleyisland'?

Why won't my app use multiple threads under 'valleyisland'?

[Chris Tapp]

I've got a recipe for an application. This has:

1) A main thread;
2) An OpenGL ('X' / EGL) graphics rendering thread created using posix threads;
3) As many threads as required from the graphics thread for GStreamer to service various pipelines.

On a Cedartrail platform this happily uses multiple cores.

However, if I use the same recipe under a 64-bit valleyisland build (daisy) it only ever uses a single core (and virtually grinds to a halt).

'top' shows CPU usage for the application never goes above 25% (J1900, so four cores available). Running four instances of 'yes' gets the total CPU usage to 100%, so all the cores are available.

'taskset' shows that the affinity mask for the application is not restricting the set of available cores.

Umm... Any ideas what's going on here?

It looks as if GStreamer and OpenGL are fighting for access to something, but the pipelines only render to 'fakesink' and 'appsink'.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

OpenSSL 1.0.0m

[Mark Evans]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

question on the openssl recipes and openssl versions... Point me to the 
correct distro if this is the incorrect spot to ask this...

We're currently on Danny, 1.3.2. In there, the openssl version is 
1.0.0j. The openssl project is currently promoting  1.0.1h. Due to the 
multiple CVEs being released, we're wanting to move to the latest. But, 
looking at the poky releases, it seems that, after "Danny", Poky 
reverted back to 1.0.0e and added patches as CVEs are released. For 
example, here's the patches in "Daisy" (1.6.1):

    openssl-1.0.1e-cve-2014-0195.patch
    openssl-1.0.1e-cve-2014-0198.patch
    openssl-1.0.1e-cve-2014-0221.patch
    openssl-1.0.1e-cve-2014-0224.patch
    openssl-1.0.1e-cve-2014-3470.patch
    openssl-CVE-2010-5298.patch

Am I reading that correct? If I move to the recipes there, will that 
close current issues on openssl? Or, is there a recipe available to use 
1.0.1h?

Thanks for any info.
Mark Evans

[-- Attachment #2: Type: text/html, Size: 1288 bytes --]

Re: OpenSSL 1.0.0m

[Khem Raj]

On Thu, Jul 24, 2014 at 5:44 PM, Mark Evans <mark.a.evans@gmail.com> wrote:
> question on the openssl recipes and openssl versions... Point me to the
> correct distro if this is the incorrect spot to ask this...
>
> We're currently on Danny, 1.3.2. In there, the openssl version is 1.0.0j.
> The openssl project is currently promoting  1.0.1h. Due to the multiple CVEs
> being released, we're wanting to move to the latest. But, looking at the
> poky releases, it seems that, after "Danny", Poky reverted back to 1.0.0e
> and added patches as CVEs are released. For example, here's the patches in
> "Daisy" (1.6.1):
>
> openssl-1.0.1e-cve-2014-0195.patch
> openssl-1.0.1e-cve-2014-0198.patch
> openssl-1.0.1e-cve-2014-0221.patch
> openssl-1.0.1e-cve-2014-0224.patch
> openssl-1.0.1e-cve-2014-3470.patch
> openssl-CVE-2010-5298.patch
>
> Am I reading that correct? If I move to the recipes there, will that close
> current issues on openssl? Or, is there a recipe available to use 1.0.1h?
>

oe-core/master is having 1.0.1h, you can backport that into your own
layer and tool your project
to use it.


> Thanks for any info.
> Mark Evans
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: OpenSSL 1.0.0m

[Mark Evans]

Thanks for the nfo. I'll go there and take a look.
--MarkE

On 7/24/2014 7:51 PM, Khem Raj wrote:
> On Thu, Jul 24, 2014 at 5:44 PM, Mark Evans <mark.a.evans@gmail.com> wrote:
>> question on the openssl recipes and openssl versions... Point me to the
>> correct distro if this is the incorrect spot to ask this...
>>
>> We're currently on Danny, 1.3.2. In there, the openssl version is 1.0.0j.
>> The openssl project is currently promoting  1.0.1h. Due to the multiple CVEs
>> being released, we're wanting to move to the latest. But, looking at the
>> poky releases, it seems that, after "Danny", Poky reverted back to 1.0.0e
>> and added patches as CVEs are released. For example, here's the patches in
>> "Daisy" (1.6.1):
>>
>> openssl-1.0.1e-cve-2014-0195.patch
>> openssl-1.0.1e-cve-2014-0198.patch
>> openssl-1.0.1e-cve-2014-0221.patch
>> openssl-1.0.1e-cve-2014-0224.patch
>> openssl-1.0.1e-cve-2014-3470.patch
>> openssl-CVE-2010-5298.patch
>>
>> Am I reading that correct? If I move to the recipes there, will that close
>> current issues on openssl? Or, is there a recipe available to use 1.0.1h?
>>
> oe-core/master is having 1.0.1h, you can backport that into your own
> layer and tool your project
> to use it.
>
>
>> Thanks for any info.
>> Mark Evans
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>

Re: [meta-intel] Why won't my app use multiple threads under 'valleyisland'?

[Darren Hart]

On Thu, Jul 24, 2014 at 09:45:41PM +0100, Chris Tapp wrote:
> I've got a recipe for an application. This has:
> 
> 1) A main thread;
> 2) An OpenGL ('X' / EGL) graphics rendering thread created using posix threads;
> 3) As many threads as required from the graphics thread for GStreamer to service various pipelines.
> 
> On a Cedartrail platform this happily uses multiple cores.

Major difference here is graphics chip, cedartrail uses EMGD binary drivers,
baytrail (valleyisland) uses the open source Intel i965 drivers.

I recently (yesterday) updated meta-intel master and daisy to properly support
video acceleration in gstreamer 1.0 - I don't know if this impacts you or not.

> 
> However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
> only ever uses a single core (and virtually grinds to a halt).
> 
> 'top' shows CPU usage for the application never goes above 25% (J1900, so four
> cores available). Running four instances of 'yes' gets the total CPU usage to
> 100%, so all the cores are available.

Does /proc/cpu list four cores?

> 
> 'taskset' shows that the affinity mask for the application is not restricting
> the set of available cores.
> 
> Umm... Any ideas what's going on here?
> 
> It looks as if GStreamer and OpenGL are fighting for access to something, but
> the pipelines only render to 'fakesink' and 'appsink'.
> 

I don't have any GL/GST development experience, so this is likely best taken to
those respective lists.

--
Darren

Re: [meta-intel] Why won't my app use multiple threads under 'valleyisland'?

[Chris Tapp]

On 29 Jul 2014, at 16:41, Darren Hart <dvhart@linux.intel.com> wrote:

> On Thu, Jul 24, 2014 at 09:45:41PM +0100, Chris Tapp wrote:
>> I've got a recipe for an application. This has:
>> 
>> 1) A main thread;
>> 2) An OpenGL ('X' / EGL) graphics rendering thread created using posix threads;
>> 3) As many threads as required from the graphics thread for GStreamer to service various pipelines.
>> 
>> On a Cedartrail platform this happily uses multiple cores.
> 
> Major difference here is graphics chip, cedartrail uses EMGD binary drivers,
> baytrail (valleyisland) uses the open source Intel i965 drivers.
> 
> I recently (yesterday) updated meta-intel master and daisy to properly support
> video acceleration in gstreamer 1.0 - I don't know if this impacts you or not.

Thanks for the pointer. I'll give it a try and see if it makes a difference.

> However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
>> only ever uses a single core (and virtually grinds to a halt).
>> 
>> 'top' shows CPU usage for the application never goes above 25% (J1900, so four
>> cores available). Running four instances of 'yes' gets the total CPU usage to
>> 100%, so all the cores are available.
> 
> Does /proc/cpu list four cores?

It does.

I've also found that running the GStreamer pipeline outside of (and at the same time as) my application works as expected - i.e. more CPU resources are used and the application runs at the target loop time, so the system can definitely do what I want...

> 'taskset' shows that the affinity mask for the application is not restricting
>> the set of available cores.
>> 
>> Umm... Any ideas what's going on here?
>> 
>> It looks as if GStreamer and OpenGL are fighting for access to something, but
>> the pipelines only render to 'fakesink' and 'appsink'.
>> 
> 
> I don't have any GL/GST development experience, so this is likely best taken to
> those respective lists.

Thanks, I've already tried that and not got anything back ;-)

> --
> Darren

Chris Tapp

opensource@keylevel.com
www.keylevel.com