Date: Sun, 29 Sep 1996 20:00:47 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Andreas Klemm <andreas@klemm.gtn.com> Cc: smp@freebsd.org Message-ID: <199609291200.UAA01014@spinner.DIALix.COM> In-Reply-To: Your message of "Sun, 29 Sep 1996 12:03:49 %2B0200." <Pine.BSF.3.95.960929115442.24135A-100000@klemm.gtn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Andreas Klemm wrote: > How stable is the smp support. > Did it ever blow up someones machine, crashing the superblock, ... > > I think about getting a smp board as the tomcat II but am not sure > if I should perhaps wait a bit ?! > > Andreas /// Well, based on what we now know about things that we don't do, I'm a little amazed that it's working as well as it seems to be in general. We are not doing TLB invalidation of other cpu's into account when modifying other processes page tables (which are possibly running on another cpu). This is a time-bomb that will affect low-memory or otherwise memory starved systems far worse than those that have plenty. (I run on 48M of ram and don't see it at all for days. I would expect 16M systems would be pretty bumpy.) The risk is probably exponentially proportional to the page-stealing rate. Although I've not heard of it happening, I would not be suprised if it can cause disk corruption, because one processor may have a read/write page in it's TLB on a running process in usermode, and the other cpu could enter the kernel, change that running processes page table to reclaim the page and assign it to a disk buffer or something. The running processor would be unaware that the physical page has been reclaimed (it's in it's TLB) and would allow the user process to modify the physical page as if it was it's data segment, even though it's been reallocated to a disk buffer or another process. I guess this means that I'm not reccomending it for a "production" system somewhere, although it's usually fine for hacking on if you've got ram. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609291200.UAA01014>