From owner-freebsd-smp Sun Sep 29 05:01:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA18915 for smp-outgoing; Sun, 29 Sep 1996 05:01:11 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA18845 for ; Sun, 29 Sep 1996 05:01:05 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id UAA01014; Sun, 29 Sep 1996 20:00:47 +0800 (WST) Message-Id: <199609291200.UAA01014@spinner.DIALix.COM> To: Andreas Klemm cc: smp@freebsd.org In-reply-to: Your message of "Sun, 29 Sep 1996 12:03:49 +0200." Date: Sun, 29 Sep 1996 20:00:47 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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