[ECOS] Unix friendly Idle loop

[ECOS] Unix friendly Idle loop

[Andrew Lunn]

Hi Folks

When the Synthetic target executes the idle thread it spins, eating
the CPU. Could this be made a bit more friendly to other processes?

I thought about installing a function in the 

HAL_IDLE_THREAD_ACTION

which calls select(2). 

Is this likly to break anything? 

        Thanks
                Andrew

--
Andrew Lunn
Research Engineer
Phone +41 62 889 52 97
Fax +41 62 889 52 90
Andrew.Lunn@ascom.ch

Ascom Systec Ltd.
Applicable Research & Technology
Gewerbepark
CH-5506 Maegenwil
Switzerland

www.ascom.com/art

Re: [ECOS] Unix friendly Idle loop

[Jesper Skov]

>>>>> "Andrew" == Andrew Lunn <lunn@ma.tech.ascom.ch> writes:

Andrew> Hi Folks When the Synthetic target executes the idle thread it
Andrew> spins, eating the CPU. Could this be made a bit more friendly
Andrew> to other processes?

Andrew> I thought about installing a function in the

Andrew> HAL_IDLE_THREAD_ACTION

Andrew> which calls select(2).

Andrew> Is this likly to break anything?

Sounds like a good idea. Two (minor) problems that need attention
though:

In case CYGIMP_IDLE_THREAD_YIELD is defined, the idle thread loop
shouldn't hang (as the select would). 

Actually, I think the rules that define CYGIMP_IDLE_THREAD_YIELD would
also need to depend on CYGSEM_KERNEL_SCHED_TIMESLICE (or idle thread
would never let threads on same priority run if timeslicing is
disabled). I'll fix this.

Second is that HAL_IDLE_THREAD_ACTION is defined per-architecture
only. The select call would be a linux specific thing, so we'll need
to support per-platform idle actions. I'll open a CR on this.

But you should definitely try it and see how it works. Let us know.

Cheers,
Jesper

Re: [ECOS] Unix friendly Idle loop

[Andrew Lunn]

> Sounds like a good idea. Two (minor) problems that need attention
> though:
> 
> In case CYGIMP_IDLE_THREAD_YIELD is defined, the idle thread loop
> shouldn't hang (as the select would). 

But we want select to hang or we don't save anything. We need to be
able to interrupt the select when an event happens that could cause a
thread to become runable. For the Synthetic target i beleave this can
only happen with a signal. Shouldn't select exist when a signal goes
off?

> But you should definitely try it and see how it works. Let us know.

Will do.

        Andrew

Re: [ECOS] Unix friendly Idle loop

[Jesper Skov]

>>>>> "Andrew" == Andrew Lunn <lunn@ma.tech.ascom.ch> writes:

>> Sounds like a good idea. Two (minor) problems that need attention
>> though:
>> 
>> In case CYGIMP_IDLE_THREAD_YIELD is defined, the idle thread loop
>> shouldn't hang (as the select would).

Andrew> But we want select to hang or we don't save anything. We need

I realize this :)

But what you want is the CPU to be free to do other host side stuff
when eCos would otherwise be idle.

When CYGIMP_IDLE_THREAD_YIELD is set it implies that the idle thread
would starve other eCos threads unless it calls yield()
repeatedly. I.e., in these (admitedly rare) configurations, your eCos
app might not behave as expected if you use the select(2) call. Some
threads may never be allowed to execute.

You are unlikely to be using such a configuration - but someone may
have to at some time. And eCos code must be safe to use with any
conceivable (valid) configuration.

In those configurations (i.e., when CYGIMP_IDLE_THREAD_YIELD is set) a
compromise might be to use nanosleep() with a suitable delay instead.


Hope my explanation makes more sense this time :)

Thanks,
Jesper

Re: [ECOS] Unix friendly Idle loop

[Jesper Skov]

>>>>> "Andrew" == Andrew Lunn <lunn@ma.tech.ascom.ch> writes:

>> Sounds like a good idea. Two (minor) problems that need attention
>> though:
>> 
>> In case CYGIMP_IDLE_THREAD_YIELD is defined, the idle thread loop
>> shouldn't hang (as the select would).

Andrew> But we want select to hang or we don't save anything. We need
Andrew> to be able to interrupt the select when an event happens that
Andrew> could cause a thread to become runable. For the Synthetic
Andrew> target i beleave this can only happen with a signal. Shouldn't
Andrew> select exist when a signal goes off?

>> But you should definitely try it and see how it works. Let us know.

Andrew> Will do.


And he did. Sent a nice patch which does indeed improve things
greatly.

I've applied the change. Should show up in the next CVS snapshot.

Cheers,
Jesper

[ECOS] When is cvs snapshot made???

[Mohammed Illyas Mansoor]

Jonathan Larmour wrote:

> Weekly normally.
>
> Jifl

        what day of the week is the cvs snapshot made?
it makes me easier to do a update automatically.


--With Regards

M. I. Mansoor

[ECOS] Re: When is cvs snapshot made???

[Jonathan Larmour]

Mohammed Illyas Mansoor wrote:
> 
> Jonathan Larmour wrote:
> 
> > Weekly normally.
> >
> > Jifl
> 
>         what day of the week is the cvs snapshot made?
> it makes me easier to do a update automatically.

Fridays, but I need to check the output, so doing a cvs update from Saturday
onwards is your best bet. It's possible I could send a mail to ecos-discuss
when I do it, but I think it would be far too noisy :-).

I can always do the snapshot manually, so if anyone knows they need a
specific update, just e-mail me. 90% of it is automated.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] Re: When is cvs snapshot made???

[Ping-Kang Hsiung, Ph.D.]

please remove me from the mailing list. Thanks.

[ECOS] Re: Unix friendly Idle loop

[Bart Veer]

>>>>> "Andrew" == Andrew Lunn <lunn@ma.tech.ascom.ch> writes:

    Andrew> When the Synthetic target executes the idle thread it
    Andrew> spins, eating the CPU. Could this be made a bit more
    Andrew> friendly to other processes?

    Andrew> I thought about installing a function in the 

    Andrew> HAL_IDLE_THREAD_ACTION

    Andrew> which calls select(2). 

    Andrew> Is this likly to break anything? 

Another possibility would be to do a nice() or setpriority() system
call during the synthetic target startup code. This would still be
annoying if you are running something like SETI@home in the
background, but otherwise it should do pretty much what you need.

Bart Veer // eCos net maintainer