From owner-freebsd-current Mon Aug 27 0:27:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 67FA337B401 for ; Mon, 27 Aug 2001 00:27:46 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA05222; Mon, 27 Aug 2001 17:27:41 +1000 Date: Mon, 27 Aug 2001 17:27:32 +1000 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Subject: Re: KSE kernel comparissons In-Reply-To: <3B896A82.DAAB4110@elischer.org> Message-ID: <20010827170927.V23439-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 26 Aug 2001, Julian Elischer wrote: > Comparative times for 'make buildworld' > for unmodified and KSE (milestone-2) kernels > > unmodified -current > 2138.464u 3358.378s 1:37:39.77 93.8% 842+1080k 45105+176988io 3208pf+0w > modified KSE kernel > 2143.716u 3363.311s 1:37:50.33 93.8% 841+1081k 45435+176988io 3214pf+0w > > I'm very glad to see that the overhead added was not too great. > (well within the margin of error I'm sure) Since it is non-negative, why would anyone want it? However, the benchmark seems to be flawed. Buildworld's system time should be only about 20% of its user time. To pessimize it by a factor of 7.5, you need to turn on lots of debugging options (which are on by default in -current). > More actual code will be needed to get away from 1:1, so this is just a > baseline. > > the next steps are for us a s a groupt to decide if this is really the way we > want to go, > and if so, whether we want to commit these changes to make them available for > the world > to work on as a base for real threading support. The alternative is to > do linux-type threading with processes (peter wemm has been investigating a > variant > on this scheme). This is probably a no-turning-back commit. How much faster (or slower) will it be for threaded programs (for various numbers of CPUs)? I don't see how it can be faster for a single CPU (interrupt threads in the kernel show that using threads tends to pessimize both efficiency and latency for a single CPU). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message