[ECOS] Fwd: [ECOS] CPU affinity in eCos

[Archana Sastry <sastry dot archana at gmail dot com>]

Hi,

@Nick: Thanks a lot for the information.

I wanted to implement something like this:

1. Maintain separate queues for each priority level. Put every
incoming thread into its respective queue.
2. Dequeue threads from a queue and schedule it to run on its
respective cpu = priority number.

In my system, I have 2 CPU's. So I wanted to know, if this is a
feasible approach?

Thanks!!

--Archana Sastry

On Fri, Oct 16, 2009 at 5:46 AM, Nick Garnett <nickg@ecoscentric.com> wrote:
>
> Archana Sastry <sastry.archana@gmail.com> writes:
>
> > Hi,
> >
> > Thanks a lot Nick.
> >
> > I am actually working on a single processor system with two hardware
> > threads. And I want to run my test on a particular processor and I
> > want this to be deterministic; which would enable me to run the same
> > test again on the same processor.
>
> eCos has even less support for hyperthreading than it does for
> SMP. The necessary instruction sequences needed to allow the hardware
> threads to synchronize properly are not present in the code.
>
> If you just want to run eCos on a single CPU, then the default non-SMP
> version of eCos will do exactly that, since it will ignore the other
> CPUs (real or virtual) and just run on the initial CPU.
>
> >
> > I am not sure if this would work, but I was wondering if the function
> > void Cyg_Scheduler_Base::set_current_thread(Cyg_Thread *thread,
> > HAL_SMP_CPU_TYPE cpu) would be of any use in this regard. This
> > function is invoked in sched.cxx and only a thread is passed to it as
> > an argument. However if I can somehow pass the HAL_SMP_CPU_TYPE cpiID,
> > would that set my current thread in such a way that it can be run
> > deterministically on that particular cpu (with ID = cpuID)?
>
> That version of set_current_thread() just sets the pointer in the
> current_thread array. It does nothing to actually schedule the thread
> onto the given CPU. In fact, such behaviour would be totally at odds
> with the general philosophy of SMP scheduling in eCos, where each CPU
> is responsible for choosing the next thread for itself, and cannot
> have a thread imposed upon it.
>
> --
> Nick Garnett ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? eCos Kernel Architect
> eCosCentric Limited ? ?http://www.eCosCentric.com ? ? ? The eCos experts
> Barnwell House, Barnwell Drive, Cambridge, UK. ? ? ?Tel: +44 1223 245571
> Registered in England and Wales: ? ? ? ? ? ? ? ? ? ? ? ? Reg No: 4422071
>

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