Date: Fri, 01 Aug 1997 10:24:30 -0600 From: Steve Passe <smp@csn.net> To: dave adkins <adkin003@gold.tc.umn.edu> Cc: smp@FreeBSD.ORG Subject: Re: interrupt latency and silo overflows in SMP since 970729 Message-ID: <199708011624.KAA22586@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Fri, 01 Aug 1997 11:07:38 CDT." <Pine.NEB.3.96.970801105738.427A-100000@samthedog.gold.tc.umn.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Dave, > > > Have there been any changes since 970729 that could have increased > > > interrupt latencies significantly in the SMP kernel? I'm used to a few > > > silo overflows now and then but kernels after 970729 have seem to have > > > increased their frequency by about a factor of ten. > > > > undef PEND_INTS in i386/include/smptests.h and let me know how it affects > > things. > ... > It was the first thing I tried. Sorry I didn't mention it in the original > post. I also disabled your profiling in mplock.s with no significant > effect (as expected). To quantify the phenomenon, with 970729 kernel I see > about 5 to 10 silo overflows per hour of connection. With 970731 kernel I > see about 100 to 150 per hour and often drop ftp and cvsup with timeouts. > The system boots on IDE but /usr and the rest are mounted on NCR SCSI so > about the only IDE activity is in /bin, /etc, and /var. > > > MotherBoard: tyan S1653D 2x200 > Bios: award 4.01 > Drives: ide, NCR scsi > > dave > > try undefing FREE_FIRST in mplock. you also might want to redefine GLPROFILE and look at the numbers. to do this hit CNTL-PRINTSCREEN to trap to the debugger, and "x gethits,6" on my machine I saw: db> x gethits,3 _gethits: 118de 1c7dd3 3f106 db> x tryhits,3 _tryhits: 9938 2196d 44cc the gethits #s refer to get_mplock calls, tryhits the try_mplock calls. the first # is the times the lock was acquired as an upgrade, ie the caller already possed it. The second # is the times the lock was acquired because it was free. the 3rd is the times that the caller had to spin waiting for it to become free (get_mplock) or the times it failed (try_mplock). Note that in the case of get_mplock the 2nd # must be adjusted by subtracting the 3rd to reflecrt the times it was found free on the first test. It would be useful to see these #s for both FREE_FIRST enabled and disabled, although I don't expect a big difference. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708011624.KAA22586>