Date: Mon, 27 Aug 2001 13:43:31 -0700 From: Peter Wemm <peter@wemm.org> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, current@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: KSE kernel comparissons Message-ID: <20010827204331.83656390B@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.21.0108271311120.74870-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
>
>
> On Mon, 27 Aug 2001, Robert Watson wrote:
>
> >
> > On Mon, 27 Aug 2001, Bruce Evans wrote:
> >
> > > 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).
> >
> > Note that we won't be able to see some of the impactmpacted until SMPng is
> > further along, where KSE will pessimize a number of single-thread
> > operations. For example, right now SMPng proc locking relies on certain
> > proc structure entries being changed only by curproc, meaning that locks
> > are held for reading only by other processes. With KSE, we'll need to
> > actually hold real locks when acting on those curproc entries (in
> > particular, reads) which may impose a substantial performance overhead. I
> > would anticipate that a number of the other potential shortcuts in SMPng
> > would be similarly impacted by KSE. However, since SMPng is very much a
> > work in progress right now, that's not something I think we can quantify
> > yet.
> >
> > This general issue does raise a lot of concerns however -- many locking
> > assumptions in SMPng will need to be changed, and the locking will need to
> > be much more thorough before we can move forward. Even pre-SMPng, we've
> > had race issues relating to unexpected sleeps, this will only get more
> > hairy (although architecturally better) with SMPng. I'm worried that
> > throwing KSE into the mix is going to hurt a lot.
>
> The curernt KSE kernel is the point in the development
> where there is only ever one thread per process.
> this is the point where we start adding code that doesn't assume this
> to replace code that does assume this.
> That is why this is a good place to do the commit.
For what it is worth, I am in agreement with Julian. The KSE code is at
an ideal "checkpoint" stage, but we must not rush it and screw things up.
The main reason that I would like it to be committed soon is that it
reduces the amount of "moving target" that the KSE part of the work has to
track. The bulk of the current changes in the current diffs are API related
and dont really change the core structural things too much. Trying to keep
a live branch up to date *and* implement the structural changes is a tall
order. We saw what happened to the BSD/OS folks, they spent 2 or 3 days
a week catching up to the current tip of tree, and only ~2 days on actual
SMP work. If we get this checkpoint into the main tree in a timely fashion
then we get the bulk of the tree-chasing out of the way and can implement
${Your_favorite_thread_frontend} at your leisure. Heck, this stuff is
generic enough that it is required for any of the thread systems, be it
full-blown KSE, or the NetBSD style lwp/sa, or linuxthreads style things,
or whatever.
If any committers want to get involved, there is a stale p4 quickstart
guide at: http://people.freebsd.org/~peter/p4cookbook.txt. You can
check out //depot/projects/kse/sys/... and review to your hearts's content.
My personal check list before committing it to -current is:
- an honest shot at getting the Alpha working. Shouldn't be too hard.
I'll work on this if nobody else will.
- finish the userland build stuff.
- carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc.
- take a look at ports impact and prepare them for the landing.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010827204331.83656390B>