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.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
