From owner-freebsd-current Mon Aug 27 11:53: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0448037B401; Mon, 27 Aug 2001 11:52:58 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA13864; Mon, 27 Aug 2001 14:52:08 -0400 (EDT) Date: Mon, 27 Aug 2001 14:52:08 -0400 (EDT) From: Daniel Eischen To: Robert Watson Cc: Bruce Evans , Julian Elischer , current@FreeBSD.ORG Subject: Re: KSE kernel comparissons In-Reply-To: Message-ID: 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 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. I'm not sure I understand completely. Our current process lock is still the same, especially since everything is single KSE'd (threaded) unless explicitly enabled. As long as we don't try to push down the process lock any further (for now) into the KSE structures, what's the difference? This will get the code into the base kernel and make those doing the locking aware of what will be needed in the future. You don't have to change process locking until you're ready to. I don't even care right now whether we can have multiple KSEs or KSE Groups. Just a single KSE is enough for us to start. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message