Jump to ID:
Multimedia

Project Home

Documents

Discussions

Wiki

Project Info
Forum Topic - purpose of mme-generic job engine idle threads?: (6 Items)
   
 
 
purpose of mme-generic job engine idle threads?  
A customer is requesting any information possible regarding the purpose of the mme-generic "job engine idle" threads--
what do they do?

My own question --do we have control over how much CPU the job engine idle threads consume (maybe a high watermark) when
 they run?

I know this is a really open-ended question, but any feedback welcome. 

~asherk
Re: purpose of mme-generic job engine idle threads?  
> A customer is requesting any information possible regarding the purpose of the
>  mme-generic "job engine idle" threads--what do they do?
> 
> My own question --do we have control over how much CPU the job engine idle 
> threads consume (maybe a high watermark) when they run?
> 
> I know this is a really open-ended question, but any feedback welcome. 

These threads are currently used for getting metadata (mme_metadata_getinfo_*), they are used for image processing and 
they are also used to processing mediastore state changes, i.e. when a device is plugged in one of these threads handles
 all of the work that needs to be done.

In the future, new mme features that require work to be done in parallel would use these threads instead of spawning 
their own local threads. There is no way to control how much CPU they consume.

Gilles


RE: purpose of mme-generic job engine idle threads?  
Can't we put these processes in partitions, and control their CPU usage
that way?
- Ed
 
>> A customer is requesting any information possible regarding the
purpose of the
>> mme-generic "job engine idle" threads--what do they do?
>> 
>> My own question --do we have control over how much CPU the job engine
idle 
>> threads consume (maybe a high watermark) when they run?
>> 
>> I know this is a really open-ended question, but any feedback
welcome.
>
> These threads are currently used for getting metadata
(mme_metadata_getinfo_*), > they are used for image processing and they
are also used to processing
> mediastore state changes, i.e. when a device is plugged in one of
these threads
> handles all of the work that needs to be done.
>
> In the future, new mme features that require work to be done in
parallel would use
> these threads instead of spawning their own local threads. There is no
way to
> control how much CPU they consume.
>
> Gilles
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post47106
Re: purpose of mme-generic job engine idle threads?  
Yes.   APS is always an option.

Dan


On 2010-02-11, at 10:31 AM, Edward Lee wrote:

> Can't we put these processes in partitions, and control their CPU usage
> that way?
> - Ed
> 
> >> A customer is requesting any information possible regarding the
> purpose of the
> >> mme-generic "job engine idle" threads--what do they do?
> >>
> >> My own question --do we have control over how much CPU the job engine
> idle
> >> threads consume (maybe a high watermark) when they run?
> >>
> >> I know this is a really open-ended question, but any feedback
> welcome.
> >
> > These threads are currently used for getting metadata
> (mme_metadata_getinfo_*), > they are used for image processing and they
> are also used to processing
> > mediastore state changes, i.e. when a device is plugged in one of
> these threads
> > handles all of the work that needs to be done.
> >
> > In the future, new mme features that require work to be done in
> parallel would use
> > these threads instead of spawning their own local threads. There is no
> way to
> > control how much CPU they consume.
> >
> > Gilles
> > _______________________________________________
> >
> > General
> > http://community.qnx.com/sf/go/post47106
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post47149
> 
> 

Dan Cardamore
dcardamore@qnx.com



Post Deleted
Re: RE: purpose of mme-generic job engine idle threads?  
> Can't we put these processes in partitions, and control their CPU usage
> that way?

Are they actually known to consume too many CPU cycles?  Is their priority perhaps too high relative to other components
?