This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: issues/suggestions related to scheduler start function


Brij Bihari Pandey <fuzzhead012@yahoo.com> writes:

> hi folks,
> 
> looking at the code of scheduler start, I have some issues/suggestions
> regarding scheduler start function.
> 
> * won't it be making some difference to code size and speed up a little (though
> by miniscule amount, but considering embedded devices, every byte saved is
> useful) 
> 
> void Cyg_Scheduler::start()
> {
>     CYG_REPORT_FUNCTION();
> 
> #ifdef CYGPKG_KERNEL_SMP_SUPPORT
>     HAL_SMP_CPU_TYPE cpu;
> ++  HAL_SMP_CPU_TYPE curcpu = CYG_KERNEL_CPU_THIS();
> 
>     for( cpu = 0; cpu < CYG_KERNEL_CPU_COUNT(); cpu++ )
>     {
>         // Don't start this CPU, it is running already!
> --      if( cpu == CYG_KERNEL_CPU_THIS() )
> ++      if( cpu == curcpu )
>             continue;
> 
>         CYG_KERNEL_CPU_START( cpu );
>     }
> #endif
> 
>     start_cpu();
> }


CYG_KERNEL_CPU_THIS() should be a cheap operation, a couple of
instructions at best. As it stands the code is clear and
concise. There seems little point in unnecessarily complicating it
for almost no gain.

> 
> * if someone enables SMP configuration but for single processor, then it will
> CYG_KERNEL_CPU_START(cpu) already running CPU. will that create any
> problems?

No it won't. Reread the piece of code above.

> 
> * if you have say, 3 processors (0,1,2), and you are allowed to use any
> processor as startup processors. You configure for 2 processors, but use
> processor no. 2 (3rd processor) as the startup processor, existing code will
> endup firing 3 processors for a 2 processor configuration and some of the data
> structures will be well messedup.

So don't do that. Or if you do, you get what you deserve.

> 
> could these smart acts (if possible to be done by users) be taken care of by
> some logic implplemented in this function?

There seems little point in complicating the code to cope with all the
obscure and daft things that some users on some weird hardware might
get up to. eCos is intended for engineers who are expected to have at
least half a clue about what they are doing.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]