From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29774 invoked by alias); 23 May 2002 14:48:35 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 29752 invoked from network); 23 May 2002 14:48:32 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 23 May 2002 14:48:32 -0000 Received: from localhost.localdomain (dell-paw-2.cambridge.redhat.com [195.224.55.226]) by executor.cambridge.redhat.com (Postfix) with ESMTP id 34421ABB0A; Thu, 23 May 2002 15:48:31 +0100 (BST) From: Gary Thomas To: Daniel.Lidsten@combitechsystems.com Cc: ecos-discuss@sourceware.cygnus.com In-Reply-To: <2253171AF143D21185A60000F8FA748B04840BD4@pluto.combitech.se> References: <2253171AF143D21185A60000F8FA748B04840BD4@pluto.combitech.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 23 May 2002 07:48:00 -0000 Message-Id: <1022165311.20571.336.camel@hermes> Mime-Version: 1.0 Subject: RE: [ECOS] interrupts X-SW-Source: 2002-05/txt/msg00284.txt.bz2 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