From owner-freebsd-smp Fri Feb 5 07:25:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00860 for freebsd-smp-outgoing; Fri, 5 Feb 1999 07:25:44 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00850 for ; Fri, 5 Feb 1999 07:25:42 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id KAA07321; Fri, 5 Feb 1999 10:18:48 -0500 (EST) From: Peter Dufault Message-Id: <199902051518.KAA07321@hda.hda.com> Subject: Re: Any documentation on SMP support on 3.0? In-Reply-To: <199902051428.JAA01004@y.dyson.net> from "John S. Dyson" at "Feb 5, 99 09:28:23 am" To: dyson@iquest.net Date: Fri, 5 Feb 1999 10:18:46 -0500 (EST) Cc: mestery@visi.com, dyson@iquest.net, rcarter@pinyon.org, grog@lemis.com, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Yes... I have to split some of it up for clarity. I am using some of the > low level FreeBSD parts for the G2 kernel -- to bootstrap progress. It would > be useful to get some fixes in for FreeBSD so that I can keep in sync > easier :-). > > I have alot of fixes that would likely require a committer to maintain, but > there are some fixes that are simple, and seem to have a significant positive > effect. I have the scheduler stuff split out for my own reasons. I'll be committing it as soon as I check it against -current again. You can look at the PATCHES.sched in my home directory to see how I've split it out and if you can slip into the same modules (synch_FOO in kern_synch) then it will be easy to put this stuff in its own .c file and make it easy to play with. With those patches I see about 5% fewer context switches during a build world but there is no net improvement because system time is up from all the function calls. I'm not concerned about the function call overhead - things can be macroized later - I'm interested in decoupling and evaluating things now. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message