Date: Wed, 21 May 1997 14:03:39 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: brett@lariat.org (Brett Glass) Cc: gurney_j@resnet.uoregon.edu, rberndt@nething.com, WELCHDW@wofford.edu, HARDWARE@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards Message-ID: <199705210433.OAA08916@genesis.atrad.adelaide.edu.au> In-Reply-To: <3.0.1.32.19970520181142.00734e08@lariat.org> from Brett Glass at "May 20, 97 06:11:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass stands accused of saying: > At 07:44 PM 5/20/97 -0700, you wrote: > >change (input, signal change)... probably what should go in before this > >is splitting the intrrupt routine to only scan the ports that are on a > >certain board... this shouldn't be THAT hard to do... and I've thought > >about doing it... > > I was under the impression that this is what was already done, but now that > I look at it, I see that you're right! The code loops on a variable called > "unit", incrementing it from 0 to the precompiled constant NSIO. This can > waste a great deal of time, especially since the interrupts are > edge-triggered and the list is scanned at least twice per interrupt. You would still have to scan all possible ports and consult their softc 'master' port value. Just scanning the port directly is not much more inefficient, and may save you interrupt overhead soon therafter. > Here are some other improvements that could be made to the code, based on a > quick analysis: > > 1) The code looks at a flag called "gone" on each and every port (present > or not) during each and every interrupt service. Since the presence or > absence of a port is determined at boot time This is not true. Please note where the "gone" flag is manipulated, and post a correction to your statement when you understand. >, it'd be MUCH more efficient > if the code worked down a linear list of only the ports that were present > and on the relevant IRQ. This might well be achievable, but is unlikely to be significantly more efficient. > list instead of stopping at the point of the last interrupt service. In > fact, it may scan as many as NSIO-1 extra ports on each interrupt. On a > system with a many serial ports, this is a LOT of extra time. It's not, actually, all that much. Scanning a port is a single I/O operation, taking around 1us. At 115200bps, it takes 86us for a single character to arrive. > Also, rather than dereferencing the pointer "com" again and again, the ISR > could selectively enregister parts of the record that contain the comm > port's statistics. This is an operation possibly best left to the compiler. Have you checked the generated machine instructions? > I don't know what the policy on ASM code is in FreeBSD, but this seems like > an opportunity to do some VERY serious optimization where it's much needed! Processor-specific code in device drivers is not a viable proposition, given that portability is a significant issue. > --Brett -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705210433.OAA08916>