Tuning Streams

Peter Brouwer pb at idca.tds.PHILIPS.nl
Mon Mar 19 20:29:13 AEST 1990


 In article <27916 at cup.portal.com> thinman at cup.portal.com (Lance C Norskog) writes:
>Ummmmm, I just remembered something.  The reason you see lots of time
>charged to the splx() kernel routine is because kernel profiling is
>very screwy in regards to interrupts, and all time spent in device 
>interrupts is 'adjusted' (in a peculiar way) right after the splx()
>routine drops interrupts to 0.  It's not really spending all that time
>fiddling the PIC's.
>
I think this is a reaction of a previous posting of me , stating a lot of
time in spend in spl routines. ( varying from 10 - 30% depending on the
drivers usage of streams ).
I did not measure this with the kernel profiler, you are correct this gives
inaccurate results. 
I did measure this with what's called a soft analist. This is simply said
a very clever logical analyser. It looks at the pins of the chip , in this
case a 386 , and samples the events there at 200ns interval.
You load in the software of the analyser the symbol table of the software
to be measured ( /unix in this case ) and specify which functions you want
to measure.
In the performance mode it lists the number of times the function is
called and total time spend in it. ( average, min and max are options )
This is where I got my info from. These figure are very accurate.
I also did a test by patching in the kernel spltty to splhi.
I measured responce times of an order entry application (16 users )
with the patched kernel. They went down from an average of 1 sec to 0.82
seconds.  The cpu time went down with 8% .
This application does terminal io on streams bases terminals.
So you see the influence of the setpicmask function in the spl handling.
-- 
Peter Brouwer,                # Philips Telecommunications and Data Systems,
NET  : pb at idca.tds.philips.nl # Department SSP-P9000 Building V2,
UUCP : ....!mcsun!philapd!pb  # P.O.Box 245, 7300AE Apeldoorn, The Netherlands.
PHONE:ext [+31] [0]55 432523, # 



More information about the Comp.unix.i386 mailing list