From owner-freebsd-hackers Wed Feb 14 23:39:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA17705 for hackers-outgoing; Wed, 14 Feb 1996 23:39:53 -0800 (PST) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA17698 for ; Wed, 14 Feb 1996 23:39:49 -0800 (PST) Received: from noel.cs.rice.edu (noel.cs.rice.edu [128.42.1.136]) by cs.rice.edu (8.7.1/8.7.1) with ESMTP id BAA02417; Thu, 15 Feb 1996 01:39:47 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by noel.cs.rice.edu (8.7.3/8.7.3) with ESMTP id BAA16225; Thu, 15 Feb 1996 01:39:47 -0600 (CST) Message-Id: <199602150739.BAA16225@noel.cs.rice.edu> To: hackers@freebsd.org cc: alc@cs.rice.edu Subject: Re: VM question Date: Thu, 15 Feb 1996 01:39:46 -0600 From: Alan Cox Sender: owner-hackers@freebsd.org Precedence: bulk > > Actually, I'd like to implement a sort of DSM that provides > > page-in/out over the network transparently to the user process. > > well, having done some of these myself I can tell you: the freebsd signal > handling code is not quite there and so won't tell you what you need to > know when a sigsegv/sigbus happens, to wit: you can't tell what type of > fault occurred (read or write). It is now giving you the faulting virtual > address, which is an improvement. I recently ported the TreadMarks DSM system developed by my group at Rice to FreeBSD 2.1. Overall, I'm pleased with the performance. TreadMarks uses UDP for interprocessor communication, so the speed of the networking code (compared to SunOS, IRIX, etc.) makes a real difference. I agree with Ron that it would be nice if the signal handler told you whether the sigbus was caused by a read or a write. Currently, I have to assume that a sigbus on an invalid (PROT_NONE) page is a read, and fault again (after changing the page to PROT_READ) if, in fact, it's a write. However, that's not the worst problem. All of the VM systems derived from Mach/OSF (except DEC UNIX) have a severe performance problem when you start mprotect'ing thousands of pages individually. The vm map list eventually has one entry per page. Consequently, sigbus and mprotect take forever, because the underlying mechanisms search the vm map list. (The hint kept in the vm map actually doesn't help much.) My group is fairly serious about using FreeBSD for our research (and publishing results based on it). So I'd love to discuss this in more detail with the developers responsible for the VM system. I believe that coallescing adjacent vm map entries (where possible) would solve 90% of the problem for us. Alan P.S. If you'd like to know more about TreadMarks, please see our web page at http://www.cs.rice.edu/~willy/TreadMarks/overview.html or the article appearing in the Feb issue of IEEE Computer magazine.