Date: Mon, 17 Jun 1996 14:12:28 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: terry@lambert.org, freebsd-smp@freebsd.org Subject: Re: linux 2.0 vs FreeBSD -current's SMP support Message-ID: <199606172112.OAA08588@phaeton.artisoft.com> In-Reply-To: <199606171955.MAA12356@rah.star-gate.com> from "Amancio Hasty" at Jun 17, 96 12:55:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Say how stable is the current SMP stuff I noticed your posting about > a week ago or so (make -j)... I have noticed some stability problems with multiple processes going into the kernel. I haven't bothered tracking them down, but it seems related to page cachability -- it may be that the non-cacheable bit is not set on the mutex page, so each processor is getting a stale mutex and thinks it's OK to go in, or more likely, it's a result of the change to the scheduling algorithm from Jack Vogel's original code. You can pretty easily force a panic by going through an interruptible device (ie: an ethernet card) by: 1) open an xterm on another system acting as an X server 2) open a second xterm 3) start a build in one of the windows 4) do file I/O in the other (running elm, whatever). You will get a page-not-present panic, eventually, assuming you have little enough RAM to cause swapping (I have 16M in my system). I'm not horribly impressed with the scheduling algorithm, compared to what it used to be, because of the "jittery nature" of the windows, you only have the opportunity to start both processors in user space once per quantum, and if you have a real active process, one processor can starve for mutex. This is kind of an inevitable result of using "idle processes" instead of a tight scheduler loop to do the work. I was able to get in a state where my console login was running on one processor and the xterm running the "build world" on the other, and the new scheduler prevented me from getting keyboard interrupts from the keyboard because the active out-of-kernel processor was the AP, so the BP starved for opportunity to service interrupts. It looks like this is actually the source of the de0 errors I reported on the -current list a bit ago. In any case, Peter has described a bunch of patches that he has yet to commit to the SMP tree, some of which seem like they will improve things (not nearly so well as removing the idle process accounting would save us from dealing with a constant 2.00 load when nothing was running on the system save the idle procs). I offered to hack on some of this, but Peter's response implied that we should wait for his patches. I'm now looking at the panic Jeffrey Hsu was seeing after his Lite2 integration patches (which have not been merged because of the panic). Once that is done, I can have some real hope of getting my FS patches in, and from there we can start looking at fixing up kernel reentrancy and testing runnable for processes on kernel exit (initially) and go on to multithreading (eventually), at system call trap time. >From what I can tell, the code is at least as stable as the Linux code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606172112.OAA08588>