Re: [ECOS] simple eCos profiler

[Gary Thomas <gary at chez-thomas dot org>]

On Wed, 2002-07-31 at 03:59, NavEcos wrote:
> 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?
> 

Note that this code only executes if the debug (console) channel is via
a network connection.  Having such implies that you _want_ network 
debugging to be available.  If this is the case, then you simply need to
expect to pay the cost of supporting it.

Your suggestion would probably render the network debugging useless or
nearly so, sorry.  The simplest solution is to use a serial port for
the debug channel (RedBoot can still load your program via the network).
Then this cost will nearly vanish (there will still be a small cost for
checking for ^C on the serial port, but it is a very quick test).

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



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