From owner-freebsd-hackers Fri Nov 10 11:20:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA07833 for hackers-outgoing; Fri, 10 Nov 1995 11:20:24 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA07818 for ; Fri, 10 Nov 1995 11:19:52 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04103; Fri, 10 Nov 1995 12:14:20 -0700 From: Terry Lambert Message-Id: <199511101914.MAA04103@phaeton.artisoft.com> Subject: Re: larry: you might want to add this to lmbench (but i'm not sure) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Fri, 10 Nov 1995 12:14:20 -0700 (MST) Cc: lm@slovax.engr.sgi.com, hackers@FreeBSD.org, waa@aurora.cis.upenn.edu, deraadt@theos.com, chuck@maria.wustl.edu In-Reply-To: from "Ron G. Minnich" at Nov 10, 95 11:15:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2476 Sender: owner-hackers@FreeBSD.org Precedence: bulk > this program does a very simple thing: > 1) open a file > 2) call write with an invalid address, viz: > write(fd, x, 5); > where x is (void *) 0x40000000 > > it does this as many times as you ask. What it's measuring is correlated > to the raw performance of the system's ability to look up a vm region or > segment or object given a virtual address. It is not a pure measure, > since systems that do a lot of work before checking the arguments > (freebsd) will fare worse than systems that just check the arguments up > front for validity (linux). On the other hand, all the system calls that > happen a lot have to do this operation, so you probably want this type of > thing to be fast. I'm sorry for the tone of what follows, but this is a stupid benchmark. On a kernel multithreaded system, and moreso in the case of SMP, prechecking opens a nice window unless you combine it with a reservation mechanism on the order of the mechanism employed by the VFS system in FreeBSD, but applied to memory ranges. Linux does prechecking and they have SMP and kernel multithreading, which leads to some nice races through which you can get system priveledges. This is basically the same race you use to bust security on an NT system, since it does the same type of prechecking without reservation. Clearly, these people do not understand multithreading sufficiently. I'm an advocate of prechecking before doing the operation in BSD, but without concommitant changes for establishing a reservation in the case of a non-failure and some mechanism for giving up the reservation in case of a different failure (the same type of layering problem the VFS currently has with cn_pnbuf), there's no way that prechecking can be considered a win. So in Linux, it's a loss on security, even if it is a win on time. And once the security issues are addressed, the "win" will be more expensive on successful operations. Any benchmark that promotes optimization of failure cases is critically flawed, and anyone who then spends time to get a better score on that benchmark silly in the extreme. You must have explicitly turned off SIGSEGV and SIGBUS in order to perform these tests. One wonders how much of your time is spent in the sigtrampoline code: another case of a failure path requiring optimization to better the score. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.