[ECOS] pthread processor binding

[ECOS] pthread processor binding

[Ahmed Abdelkhalek]

Hi everyone,

Some pthread implementations allow binding a thread
for execution on a particular processor or a set of
processors (google pthread_pset_bind_np). Are there
plans to include this in future ecos realeases?

Thanks,
Ahmed


 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Andrew Lunn]

On Wed, Feb 14, 2007 at 04:07:56PM -0800, Ahmed Abdelkhalek wrote:
> Hi everyone,
> 
> Some pthread implementations allow binding a thread
> for execution on a particular processor or a set of
> processors (google pthread_pset_bind_np). Are there
> plans to include this in future ecos realeases?

None that i know of. Does this even make sense in an RTOS? I've not
thought about this long enough to answer that question...

Anyway feel free to implement it yourself.

       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Ahmed Abdelkhalek]

It may make sense especially on a heterogeneous MP
platform, where you might want to bind certain threads
that do expensive work on more capable processors, and
other less demanding threads to cheaper cores.

--- Andrew Lunn <andrew@lunn.ch> wrote:

> On Wed, Feb 14, 2007 at 04:07:56PM -0800, Ahmed
> Abdelkhalek wrote:
> > Hi everyone,
> > 
> > Some pthread implementations allow binding a
> thread
> > for execution on a particular processor or a set
> of
> > processors (google pthread_pset_bind_np). Are
> there
> > plans to include this in future ecos realeases?
> 
> None that i know of. Does this even make sense in an
> RTOS? I've not
> thought about this long enough to answer that
> question...
> 
> Anyway feel free to implement it yourself.
> 
>        Andrew
> 



 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Nick Garnett]

Ahmed Abdelkhalek <oneshotawp@yahoo.com> writes:

> It may make sense especially on a heterogeneous MP
> platform, where you might want to bind certain threads
> that do expensive work on more capable processors, and
> other less demanding threads to cheaper cores.

eCos SMP support is fairly simple, it assumes equal CPUs and uniform
memory access. It certainly cannot cope with CPUs of varying
performance and capabilities. There is no way it could cope with
heterogeneous CPUs. Neither could it cope with NUMA systems.

If you want to run a single OS image on a strongly asymmetric system
then eCos is probably not the place to start. The additional
complexity needed, while acceptable in a large OS like Linux, is
excessive for a small OS like eCos.

-- 
Nick Garnett                                          eCos Kernel Architect
http://www.ecoscentric.com                     The eCos and RedBoot experts
Besuchen Sie uns vom 13.-15.02.07 auf der Embedded World 2007, Stand 11-336
Visit us at Embedded World 2007, Nürnberg, Germany, 13-15 Feb, Stand 11-336


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Andrew Lunn]

On Wed, Feb 14, 2007 at 04:07:56PM -0800, Ahmed Abdelkhalek wrote:
> Hi everyone,
> 
> Some pthread implementations allow binding a thread
> for execution on a particular processor or a set of
> processors (google pthread_pset_bind_np). Are there
> plans to include this in future ecos realeases?

Just thinking aloud here...

With an ROTS, which implements prioritized threads, the scheduler runs
the highest priority runnable thread. With SMP, it runs the highest
priority runnable threads, which could potentially be at different
priorities, but i don't think that really matters. You probably get
better performance if you have some level of processor affinity,
i.e. if possible run a thread on the same CPU as it was run last time,
with the hope it still has something useful in the cache. However a
runnable thread should not be left runnable but not run because the
last CPU it ran on is busy when another CPU is available. If you did
leave the thread runnable, you have to either leave the CPU unused,
which is probably wasteful or run a thread of lower priority. That
goes against the principle of the highest priority runnable threads
are the once that runs.

So to me, it seems like in an SMP RTOS, binding threads to processors
to will actually hinder RT operation.

   Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Ahmed Abdelkhalek]

Thanks for the reply Nick.

I was under the impression it would be possible with
eCos, given other RTOSs (like RTEMS) support
heterogeneous multiprocessor systems.

Also, I thought the HAL was there to provide the
necessary abstraction between the hardware and the OS.
So having heterogeneous cpus could be taken care of by
including several compilations of the HAL for each
arch, with appropriate "glue".

Am I missing something?

Thanks,
Ahmed

--- Nick Garnett <nickg@ecoscentric.com> wrote:

> Ahmed Abdelkhalek <oneshotawp@yahoo.com> writes:
> 
> > It may make sense especially on a heterogeneous MP
> > platform, where you might want to bind certain
> threads
> > that do expensive work on more capable processors,
> and
> > other less demanding threads to cheaper cores.
> 
> eCos SMP support is fairly simple, it assumes equal
> CPUs and uniform
> memory access. It certainly cannot cope with CPUs of
> varying
> performance and capabilities. There is no way it
> could cope with
> heterogeneous CPUs. Neither could it cope with NUMA
> systems.
> 
> If you want to run a single OS image on a strongly
> asymmetric system
> then eCos is probably not the place to start. The
> additional
> complexity needed, while acceptable in a large OS
> like Linux, is
> excessive for a small OS like eCos.
> 
> -- 
> Nick Garnett                                        
>  eCos Kernel Architect
> http://www.ecoscentric.com                     The
> eCos and RedBoot experts
> Besuchen Sie uns vom 13.-15.02.07 auf der Embedded
> World 2007, Stand 11-336
> Visit us at Embedded World 2007, Nürnberg, Germany,
> 13-15 Feb, Stand 11-336
> 
> 



 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Ahmed Abdelkhalek]

I agree with what your saying Andrew. Perhaps if I
disable timeslicing I can ensure a thread will run
until completion (or until locality is no longer a
concern) before yielding the processor. I'd have to
make sure starvation doesn't occur though for some
threads.

This is possible though, right?

Ahmed

--- Andrew Lunn <andrew@lunn.ch> wrote:

> On Wed, Feb 14, 2007 at 04:07:56PM -0800, Ahmed
> Abdelkhalek wrote:
> > Hi everyone,
> > 
> > Some pthread implementations allow binding a
> thread
> > for execution on a particular processor or a set
> of
> > processors (google pthread_pset_bind_np). Are
> there
> > plans to include this in future ecos realeases?
> 
> Just thinking aloud here...
> 
> With an ROTS, which implements prioritized threads,
> the scheduler runs
> the highest priority runnable thread. With SMP, it
> runs the highest
> priority runnable threads, which could potentially
> be at different
> priorities, but i don't think that really matters.
> You probably get
> better performance if you have some level of
> processor affinity,
> i.e. if possible run a thread on the same CPU as it
> was run last time,
> with the hope it still has something useful in the
> cache. However a
> runnable thread should not be left runnable but not
> run because the
> last CPU it ran on is busy when another CPU is
> available. If you did
> leave the thread runnable, you have to either leave
> the CPU unused,
> which is probably wasteful or run a thread of lower
> priority. That
> goes against the principle of the highest priority
> runnable threads
> are the once that runs.
> 
> So to me, it seems like in an SMP RTOS, binding
> threads to processors
> to will actually hinder RT operation.
> 
>    Andrew
> 



 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Andrew Lunn]

On Thu, Feb 15, 2007 at 10:00:47AM -0800, Ahmed Abdelkhalek wrote:
> 
> Thanks for the reply Nick.
> 
> I was under the impression it would be possible with
> eCos, given other RTOSs (like RTEMS) support
> heterogeneous multiprocessor systems.
> 
> Also, I thought the HAL was there to provide the
> necessary abstraction between the hardware and the OS.
> So having heterogeneous cpus could be taken care of by
> including several compilations of the HAL for each
> arch, with appropriate "glue".
> 
> Am I missing something?

eCos is designed to have just one HAL. A lot of the interfaces to the
HAL are implemented using #define's. So it will be very difficult to
change this.

It is important to remember eCos is primarily designed for small
deeply embedded systems. SMP is not usual for such systems and AMP
even less so.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread processor binding

[Andrew Lunn]

On Thu, Feb 15, 2007 at 10:05:08AM -0800, Ahmed Abdelkhalek wrote:
> 
> I agree with what your saying Andrew. Perhaps if I
> disable timeslicing I can ensure a thread will run
> until completion

Or a higher priority thread becomes runnable, and it will preempt it.

> This is possible though, right?

Yes, this is possible.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss