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.
This kernel is logcally the same as a non-KSE one. For example,
a process lock is sufficient to alter proc or thread structures,
because they are always 1:1
Adding this commit does not alrter the work needed to get SMP
locking pushed down to a few subsystems.
What it DOES do is allow people to look at what is coming.
It also means that the P4 integration taks is greatly reduced
as changes to device drivers etc will probably not produce clashes,
(where at the moment almost any change meens an integration run for me).
If I wait to check in, then I have to check in code that starts to be
logically different to what is there now. (because that is what I will be
working on and keeping lockstepped with -current).
Either that or I stay frozen and unable to proceed until 5.1 or 6.0
or whenever.
If we check in what I have now then everyone's changes will already
match and people can start to think abnout how their changes will
be effected by threads.
WIth a couple of weeks at this point we should be able to make
this exactly as reliable as -current is now, and get the other
ports also at the same state as i386.
When that is doen I am quite happy to go off doing further development
on a p4 branch again for a couple of months more, because the
integration load will be MUCH less, and because others wil be able to
see where we are going.
What I'm trying to say, is that this is the right time to commit it
becasue it will have minimum impact on -current and maximim impact on
KSE. If we delay, the impact on -current will be much greater, because
parts of the system will no-longer be assuming that the proc:thread
relationship is 1:1. This stage is a mostly mecahnical edit, that
can be easily verified against what is there previously.
If we wait we will starrt to get changes that are NOT so easily verified.
I would like to get THIS stage checked in so that editing mistakes
can be weeded out now while they are trivial. That wil give me a solid
base on which to do teh real LOGICAL changes. If we wait
then when I commit, I will be committing both sets of changes at once.
My timeline would be to get the other ports (and boris's filesystems)
done in the next two weeks and have a bunch of people try it on
different hardwware.
In tow weeks when we've proved equivalent reliability,
I'd commit. Then We start affresh with p4, working up a
new set of changes. THIS set I would not base off -current
but rather off JOhn's SMP/locking branch.
In other words I'd be tracking HIS work rather than just -current.
(he'd be doing MFC's and I'd be doing MFJ's)
that means that further integration for him after this commit would be
negligible..
(I need it this way because the locking is critical to the threads.)
julian
>
> 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
