From owner-freebsd-questions Sat Nov 18 22:31:24 2000 Delivered-To: freebsd-questions@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id F3D6A37B479 for ; Sat, 18 Nov 2000 22:31:21 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id eAJ6V9c26022; Sun, 19 Nov 2000 00:31:09 -0600 (CST) (envelope-from dan) Date: Sun, 19 Nov 2000 00:31:08 -0600 From: Dan Nelson To: Zero Sum Cc: Mike Meyer , Jeff Wyman , questions@FreeBSD.ORG Subject: Re: SMP: FreeBSD vs. Linux Message-ID: <20001119003108.A7283@dan.emsphone.com> References: <14870.23240.379989.419970@guru.mired.org> <00111916420801.13422@shalimar.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <00111916420801.13422@shalimar.net.au>; from "Zero Sum" on Sun Nov 19 16:42:08 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Nov 19), Zero Sum said: > I was unaware of the above, but I have been running an SMP kernel for > over a year now, tracking 3 STABLE. I have now gone 4 STABLE. I > have always been satisfied with the SMP performance, I can't see > where I'm losing anything. > > I run two copies of seti and they sit there at 99.02% cpu > utilization, each. Where am I *losing* performance? seti@home is not really a good testcase for SMP; it consumes 100% cpu and doesn't do any I/O. There are two problems with FreeBSD SMP at the moment: #1 is the kernel's "Big Giant Lock", which means that only one process can be in the kernel at any one time. This is bad news for multiple processes doing lots of I/O of any sort; disk, network, or pipe, since if one process is doing I/O, all other processes have to wait to do their I/O, even if it's to a different device. The solution is to split the big lock into multiple small ones covering different drivers/resources. See http://people.freebsd.org/~jasone/smp/ for details. #2 is our user-level pthreads library, which means that disk I/O blocks the entire process, and a threaded program is stuck on one CPU. This is bad news for programs like mysql that would really like CPU-intensive queries to be run on their own CPU, and would like a disk-intensive thread to not block a CPU-intensive thread from running. The solution is to switch to kernel-based threads ( this is a simplification; see http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html for a full discussion of the issues). Problem #1 is being worked on in the -current tree (aka the SMPng project) as we speak, and problem #2 will be addressed after #1 is complete. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message