Date: Fri, 1 Mar 2002 10:22:58 -0600 From: Nathan Kunkee <nkunkee@umr.edu> To: hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: freebsd-hackers SMP performance question Message-ID: <20020301162258.GA24102@umr.edu> In-Reply-To: <bulk.31923.20020228114416@hub.freebsd.org> References: <bulk.31923.20020228114416@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm crossposting to freebsd-smp@freebsd.org, as per suggestion. > > My original post, edited: > > > > ... why any kernels compiled with SMP enabled seem > > > to be slowing the whole system down? Throughput goes down by 40%. > Tasks > > > take twice as long to run, etc, etc... > > > ... it appears to be system-wide. And is directly linked to > > > SMP: two kernels, identical EXCEPT that one has SMP enabled, the other > not. > > > The enabled kernel that *should* be fully utilizing multi-procs is > suddenly > > > effectively running at half speed. > > Thanks to all for replies. Since i am having the same problem, I'll tack my info next to yours and see if both of us can get an answer. I'm using a dual P120, 64M ram, built my own SMP kernel, and have noticed the same thing: performance/through put slows to nothing. my best example of this is when in X I move the mouse. no mouse motion, ~6% cpu usage. move the mouse, ~40-55% usage. Are all interrupts being mapped to a single cpu?? > > Regarding my SMP query, Doc asks: > > What sort of throughput? What sort of processes are you > > running? Do you > > actually have multiple processes fighting for CPU? > > Yes, I'm using netperf, iperf or nttcp to measure TCP throughput using the > server (the box in question) in response to ten simultaneous clients. > Chariot allegedly did not show the performance hit. But then, even > measuring the process time to run a single simple script shows ~half the > speed with SMP enabled. > Yes. does KDE with konqueror (and user ppp in background) count? konqueror is so slow it is nearly unusable. I figured that dual cpus would provide closer to my K6 233 performance, meaning comfortable interaction. building the kernel (make -j2 depend; make -j2; make -j2 install) seems to take as long as a single proc.. don't have actual wall clock time, got too bored. I also have some other quirks that i think are related. Occasionaly, my scsi drive (ahb eisa) will timeout while trying to reset. loading an smp kernel helped reduce this trouble, but not eliminate it. My sound card, which works fine AFAIK in other machines, has timeout trouble in this one. how can i determine if these are hardware troubles, or SMP related?? Is there a way to dynamicaly disable/enable a cpu? so that i can disable one and see how that affects performance?? I tried sysctl machdep.smp_active=1, or =2, but according to top, no difference. both procs are still getting programs and time slices. > Chris F. asks: > > Is this an old Pentium? If so, update to a recent -stable; > > a fix was committed a few weeks ago fixing a problem where > > the caches on both processors were not enabled on Pentiums. > > Otherwise, we have a few PII and PIII boxes here that work > > quite under 4.5. > > This includes multiple configurations, incl: dual PIII 700s, dual PIII 800s, > quad PIII Zeon 550s, etc... No old procs, per se. I'm running the released > version of 4.5. Was a proc-specific fix implemented *after* its release? > yes, p120. I will endeavor to setup and download the latest this weekend. will take some time since i'm on dialup.... > Greg L states: > > It would also be interesting to see if you get the same results > > running 5-CURRENT. While this version isn't suited to production use, > > it's based on a very different implementation, and the information > > would help us work out what's going on here. > I will endeavor to get this d/l as well. again, dialup will not make this quick or easy... > Unfortunately, I do not get a whole lot of time to get experimental due to > compressed testing schedules but, if a hole opens up, I will attempt to get > some testing done using 5-CURRENT. Will report any results to you. Thanks > for your interest. > > This scenario has been replicated on several (virtually any and all) test > boxes by multiple engineers. Any other tips are greatly appreciated. > > TIA - > > -=C. Stephen Frost=- > Intel Corp. > ICG - Network Quality Labs > Software Test Engineer > 503.264.8300 > > All opinions are my own, not those of Intel Corporation As well, thanks for all the information and help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020301162258.GA24102>