Re: [ECOS] simple eCos profiler

[NavEcos <ecos at navosha dot com>]

On Wednesday 31 July 2002 02:02, Andrew Lunn wrote:
> > There is a significant amount of code, most of it is not kernel code.
> > Is it OK if I post a link to a webpage?  I just have to set one up :D
>
> Yep. Or you could use bugzilla.redhat.com. Create a new enhancement
> bug and attach the code using the attachment feature.

I'll make a webpage for it.  I'm too lazy ATM to learn yet another thing.
I'll try to get it posted within the next 24 hours.

> > > > P.S.  hal_ctrlc_check gets called a LOT and seems to get called
> > > > more, the more pings I send it.  I haven't debugged this to find out
> > > > why, but it's perplexing.  Anybody know what is going on with it?
> > >
> > > This function acts as the interface between the application network
> > > stack and redboot. Each packet received by the application is passed
> > > down to redboot to let it decide if the packet is actually for the
> > > redboot stack, not the application stack.
> >
> > Oh.  That name seem sort of obsfucated, but I get it.
>
> Its historic. The redboot network stack is a recent bolt on addition.
>
> > I will have to look at this more.  I have found that it can take up
> > significant time (like 33% of the active time) if I send enough
> > network traffic through it.
>
> That does seem a lot. It is possible to disable this, but you loose
> some of the network debugging facilities. Without this you cannot use
> ^C to interrupt a running system and tcp connections will die after a
> while since the keep alive won't happen.
>
> Actually, its possible your figure is misleading. I think interrupts
> are disabled in this function before it jumps into redboot. After
> redboot exits the function re-enabled interupts. Im guessing your
> profiler is interrupt based? So any profiler interrupts while it is in
> redboot will actually be serviced in this function once the interrupts
> are re-enabled.

Yep, you're right:

My profiler is based on the system tick interrupt.  I AM aware of
the inherit problems of doing it this way but this was the most
portable way of doing it.  For a heavily loaded system, doing it
this way shouldn't skew results too much I don't think.

Anyhow, although my figure is misleading, a lot of time is being spent
uncessarily in that function.  Perhaps a quick hack "fix" would be
keep track of the last time the function was called, and if "X" amount
of ticks hasn't elapsed, to skip the check.  This would probably
disable control-C ability for the most part of the stack is active,
but at least the keep alive should work I think?

> > I have a question.  When redboot "runs", can the application on top
> > of redboot interrupt it?  I haven't investigated the relationship
> > between the two very much.
>
> Nope.
>
>       Andrew

thanks,
-Rich

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