RE: [ECOS] interrupts

[Gary Thomas <gthomas at redhat dot com>]

On Thu, 2002-05-23 at 08:37, Daniel.Lidsten@combitechsystems.com wrote:
> >-----Original Message-----
> >From: Gary Thomas [mailto:gthomas@redhat.com]
> >Sent: den 22 maj 2002 16:00
> >To: Andersson Daniel
> >Cc: rrv@tid.es; ecos-discuss@sourceware.cygnus.com
> >Subject: RE: [ECOS] interrupts
> >
> >
> >On Wed, 2002-05-22 at 04:15, Daniel.Andersson@combitechsystems.com
> >wrote:
> >> Hi,
> >> 
> >> I read our below posting and was wondering if you maybe have 
> >come to a
> >> solution with our long ISR startup time?
> >> 
> >> Currently i have almost the same problem on my MPC850. 
> >Everytime i receive
> >> an interrupt then i get the following timeschedule: 
> >> 
> >> 0 -10us	I can see a lot of RAM access - dont know what 
> >it is but i assume
> >> that the SW investigate what 			caused 
> >the interrupt
> >> 
> >> 10-32		I enter my isr which is 250 asm 
> >instruction (it takes 22us)
> >> 
> >> 32-70		The code exits the ISR and starts doing 
> >some other SW
> >> processing that i dont know what it is. 			
> >However, i
> >> can see a lot of RAM access after that i have left the ISR but
> >> 
> >> 
> >> My question is: What can cause my CPU to execute this slow? 
> >The ISR, which
> >> is 250 instruction, takes 22us and that can be reasonable. I 
> >have looked at
> >> the caches but find them to be working - as far as i can 
> >tell at leased.
> >> 
> >
> >Have you looked at the relevant code?  (You have the sources!)
> >Most of this execution path is in 
> >hal/powerpc/arch/current/src/vectors.S
> >
> >Don't forget that eCos is designed to be general.  While it 
> >may be true 
> >that your particular interrupt can be handled in 22us, it can 
> >only do so
> >if a proper environment has been set up.  The vectors.S (the VSR code
> >actually) is responsible for saving the interrupted environment 
> >(registers, etc), figuring out to call your ISR (there are many 
> >interrupt choices, each with it's own ISR), calling your ISR and then,
> >depending on the return value, possibly setting up to run a DSR later
> >before returning to the interrupted context.
> >
> >You've not said much about your platform - MPC850 isn't sufficient
> >detail.  What about the clock speed? RAM wait states?  I can infer
> >from your note that the processor can execute approximately 10 
> >instructions per us.  If you look at the VSR, it's quite plausible
> >that 100 instructions need to be executed before calling your ISR.
> >There will be nearly as many required on the way out.  This can be
> >[somewhat] reduced by enabling 
> >CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT.
> >Also, depending on the configuration, the VSR may call into the kernel
> >after your ISR for scheduling of possible DSR routines.  This is C/C++
> >code, and it's very easy to expect it to execute the remaining 200
> >instructions.
> >
> >It all makes sense to me (your numbers).  What else is running in your
> >system?  Are you making use of the kernel, threads, etc?  If so, you
> >pretty much have to expect some overhead.
> >
> >Of course, you could always install your own VSR (there is complete
> >support for this) which tried to be ultra smart in the case of your
> >one particular interrupt, but that code would still need to be able
> >to handle other generic interrupts.
> >
> 
> You say that the taskswitch that ia have before i get to my ISR code is
> reasonable in time and now that i have examined what's actually happening
> than i have to agree. Currently i am experiencing a taskswitch time of ~10us
> and since i have such a small cache (2kb instr. and 1kb data in mpc850) then
> i dont have any of the relevante code in the caches which means that i have
> to make external access to RAM. Such access takes 40ns (burst). This means
> that a taskswitch that takes 10us actually executes 250 instruction and i
> find that ok.
> 
> My problem has at this point elevated to the position where i am unsure of
> if the MPC850 is the right CPU choise for this application.
> 
> In my application i will receive atleased 5000 interrupt/s which makes the
> context switch time a very large part of the systems total capacity. AFAIK
> then the VSR code handles _all_ interrupts, is that right? Is there any way
> of decreasing the latency on just one interrupt?
> 
> I have tried to put the entire VSR handler in dpram to speed up execution
> but i only got a 15 percent decrease which of course isnt enough.
> 
> Just hypotheoretical - what performance would i get if i used a MPC823 that
> has four times that cache size that i have in the MPC850. Could i expect
> twice the performance of the 850....?

I can't say.  It would depend a lot on what gets to stay in the caches, etc.

I think you should be answering a more fundamental question here; if you are
getting interrupts every 200us (5000/sec), what are you going to be doing
with them?  You've not said anything about your application, but it seems to
me that if you have to be doing _anything_ else in this system, you are out
of steam from the get-go.  Even if you keep the interrupt [raw] processing
time down to 70us (your original quote), that leaves a scant 130us between
interrupts for the system to be running anything else (threads, etc).


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