[ECOS] issues/suggestions related to scheduler start function

[ECOS] issues/suggestions related to scheduler start function

[Brij Bihari Pandey]

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();
}

* 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?

* 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.

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

cheers
brij
 


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_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] issues/suggestions related to scheduler start function

[Nick Garnett]

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

Re: [ECOS] issues/suggestions related to scheduler start function

[Brij Bihari Pandey]

hello nick,

> 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.

> 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.
I personally like and agree to, what you also have said.

Thanks for providing your valuable comments over things that couple of people I
have known working in embedded s/w-h/w companies, have got as the
commandments/guidelines to improve/debug the software, from their project
managers at various points in time. I hope your comments give developers
atleast some moral support, if not much.

cheers
brij



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_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