* [ECOS] pthread processor binding @ 2007-02-15 0:08 Ahmed Abdelkhalek 2007-02-15 0:45 ` Andrew Lunn 2007-02-15 13:34 ` Andrew Lunn 0 siblings, 2 replies; 9+ messages in thread From: Ahmed Abdelkhalek @ 2007-02-15 0:08 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 0:08 [ECOS] pthread processor binding Ahmed Abdelkhalek @ 2007-02-15 0:45 ` Andrew Lunn 2007-02-15 2:28 ` Ahmed Abdelkhalek 2007-02-15 13:34 ` Andrew Lunn 1 sibling, 1 reply; 9+ messages in thread From: Andrew Lunn @ 2007-02-15 0:45 UTC (permalink / raw) To: Ahmed Abdelkhalek; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 0:45 ` Andrew Lunn @ 2007-02-15 2:28 ` Ahmed Abdelkhalek 2007-02-15 10:59 ` Nick Garnett 0 siblings, 1 reply; 9+ messages in thread From: Ahmed Abdelkhalek @ 2007-02-15 2:28 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 2:28 ` Ahmed Abdelkhalek @ 2007-02-15 10:59 ` Nick Garnett 2007-02-15 18:01 ` Ahmed Abdelkhalek 0 siblings, 1 reply; 9+ messages in thread From: Nick Garnett @ 2007-02-15 10:59 UTC (permalink / raw) To: Ahmed Abdelkhalek; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 10:59 ` Nick Garnett @ 2007-02-15 18:01 ` Ahmed Abdelkhalek 2007-02-15 19:28 ` Andrew Lunn 0 siblings, 1 reply; 9+ messages in thread From: Ahmed Abdelkhalek @ 2007-02-15 18:01 UTC (permalink / raw) To: Nick Garnett; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 18:01 ` Ahmed Abdelkhalek @ 2007-02-15 19:28 ` Andrew Lunn 0 siblings, 0 replies; 9+ messages in thread From: Andrew Lunn @ 2007-02-15 19:28 UTC (permalink / raw) To: Ahmed Abdelkhalek; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 0:08 [ECOS] pthread processor binding Ahmed Abdelkhalek 2007-02-15 0:45 ` Andrew Lunn @ 2007-02-15 13:34 ` Andrew Lunn 2007-02-15 18:05 ` Ahmed Abdelkhalek 1 sibling, 1 reply; 9+ messages in thread From: Andrew Lunn @ 2007-02-15 13:34 UTC (permalink / raw) To: Ahmed Abdelkhalek; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 13:34 ` Andrew Lunn @ 2007-02-15 18:05 ` Ahmed Abdelkhalek 2007-02-15 19:31 ` Andrew Lunn 0 siblings, 1 reply; 9+ messages in thread From: Ahmed Abdelkhalek @ 2007-02-15 18:05 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] pthread processor binding 2007-02-15 18:05 ` Ahmed Abdelkhalek @ 2007-02-15 19:31 ` Andrew Lunn 0 siblings, 0 replies; 9+ messages in thread From: Andrew Lunn @ 2007-02-15 19:31 UTC (permalink / raw) To: Ahmed Abdelkhalek; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-02-15 19:31 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-15 0:08 [ECOS] pthread processor binding Ahmed Abdelkhalek 2007-02-15 0:45 ` Andrew Lunn 2007-02-15 2:28 ` Ahmed Abdelkhalek 2007-02-15 10:59 ` Nick Garnett 2007-02-15 18:01 ` Ahmed Abdelkhalek 2007-02-15 19:28 ` Andrew Lunn 2007-02-15 13:34 ` Andrew Lunn 2007-02-15 18:05 ` Ahmed Abdelkhalek 2007-02-15 19:31 ` Andrew Lunn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).