Destabilization due to SMP development

From: Jason Evans <jas...@canonware.com>
Subject: HEADS UP: Destabilization due to SMP development
Date: 2000/06/19
Message-ID: <fa.hs70e0v.1q1288p@ifi.uio.no>#1/1
Original-Date: Mon, 19 Jun 2000 11:53:30 -0700
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-ID: <20000619115330.D79318@blitz.canonware.com>
To: curr...@FreeBSD.ORG
Content-Type: text/plain; charset=us-ascii
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.freebsd.current

Summary: -current will be destabilized for an extended period (on the order
of months).  A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that tag until
the kernel stabilizes, or expect large doses of pain.  This tag will be
laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
beforehand.

---

Last week, approximately 20 BSD developers got together and discussed how
to move FreeBSD's SMP support to the next level.  Our effort will be
largely based on the work that has been done in BSD/OS, which should make
things go much more smoothly than they otherwise might, but we still expect
-current to be destabilized for an extended period of time.

Matthew Dillon is currently working on the locking primitives, as well as
some changes to the way our top-level kernel locking works.  His initial
code will not remove spl()s.  This code will probably be committed as the
first step, as soon as June 26, 00:00 PST, and Peter Wemm will lay a tag
down just beforehand.  We will give at least 24 hours notice before the tag
is laid down.  Be forewarned: if you are doing anything with -current
besides FreeBSD development, you will probably want to stop tracking
-current at that point for a while.

Greg Lehey will be working on the initial cutover to interrupt threads (as
well as the lazy interrupt thread context switching code later on).  spl()s
will go away as soon as interrupt threads start working.  Once interrupt
threads are working, most of the remaining work of threading the kernel
will be able to go on in parallel.

Device driver maintainers will be able to convert device drivers over a
period of several months.  We expect to have a compatibility shim in place
initially, but there will be a hard cutoff date sometime before the release
of FreeBSD 5.0 where the compatibility shim is removed.  Before getting too
excited about this part of the conversion to a threaded kernel, please keep
in mind that 1) there will be plenty of time to do this conversion, 2) the
conversion is pretty trivial for most drivers, and 3) as we get to the
stage where the conversion becomes possible, there will be much more detail
about how to do the conversion, as well as the working examples of the
first drivers to be converted.

The addition of kernel support for scheduler activations is generally a
separate project, but there are some interdependencies between the SMP and
scheduler activations changes, especially in the scheduler and the proc
structure.

There are many other SMP-related changes that will be made to the kernel
that are not specifically mentioned in this email, since they are not of
significant interest from a grand overview perspective.  However, there are
many details, and if you want to follow the technical discussions, you will
want to be subscribed to at least the -current and -smp mailing lists.

Finally, here are some notes about the organization of this effort.  I was
cajoled into acting as the manager of this effort.  That doesn't mean I'm
going to do all (or even a major part) of the work; it merely means I'm the
focal point of communications and decisions made with regard to the
project.  Right now, there are at least a dozen highly capable FreeBSD
developers that have taken an interest in working on this project.  We, as
a group, have made a number of decisions about how to attack this project.
If you want to contribute to technical aspects of the project, please jump
in.  However, consider that the general direction we're taking with the SMP
effort is the result of a number of very knowledgeable people hashing this
out over a period of two days; don't expect that direction to change in the
short-term.  So, if you have grievances about the way this project is being
run, complain to me, but please let the other developers work on this in
relative peace.

Jason

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: HEADS UP: Destabilization due to SMP development
Date: 2000/06/20
Message-ID: <fa.kja131v.1e78ha5@ifi.uio.no>#1/1
Original-Date: Mon, 19 Jun 2000 17:34:47 -0700 (PDT)
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-Id: <200006200034.RAA81825@apollo.backplane.com>
References: <fa.hs70e0v.1q1288p@ifi.uio.no>
To: curr...@FreeBSD.ORG
Original-References: <20000619115330.D79...@blitz.canonware.com>
Organization: Internet mailing list
Newsgroups: fa.freebsd.current

:Summary: -current will be destabilized for an extended period (on the order
:of months).  A tag (not a branch) will be laid down before the initial
:checkin, and non-developers should either stick closely to that tag until
:the kernel stabilizes, or expect large doses of pain.  This tag will be
:laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
:beforehand.
:
:---
:
:Last week, approximately 20 BSD developers got together and discussed how
:to move FreeBSD's SMP support to the next level.  Our effort will be
:largely based on the work that has been done in BSD/OS, which should make
:things go much more smoothly than they otherwise might, but we still expect
:-current to be destabilized for an extended period of time.
:
:Matthew Dillon is currently working on the locking primitives, as well as
:some changes to the way our top-level kernel locking works.  His initial
:code will not remove spl()s.  This code will probably be committed as the
:...

    Thank you Jason!

    Ok, I have put up a web page that will track my efforts.

	http://apollo.backplane.com/FreeBSDSmp/

    I got a slow start on the weekend, but I expect to have my piece
    commitable this week sometime.  When I say committable I mean: won't
    crash the system outright but will still probably panic due to legacy
    spl*() issues, which we will fix as we see them.

    I am making good progress.  In many respects it is actually easier to
    get the stuff working on a single-cpu system first since all the MP
    mechanisms must now work on a single-cpu system due to the preemptive
    kernel scheduling, but I expect I will have both single and multi-cpu
    systems working more or less (non-inclusive of interrupt threads, which
    is going to be Greg's baby, but hopefully with all the support Greg
    needs to implement them) in the next few days.

    When I get a little further along I will start making patch sets
    available on the same page.  Probably in the next day or two.

:Device driver maintainers will be able to convert device drivers over a
:period of several months.  We expect to have a compatibility shim in place
:initially, but there will be a hard cutoff date sometime before the release
:of FreeBSD 5.0 where the compatibility shim is removed.  Before getting too
:excited about this part of the conversion to a threaded kernel, please keep
:in mind that 1) there will be plenty of time to do this conversion, 2) the
:conversion is pretty trivial for most drivers, and 3) as we get to the
:stage where the conversion becomes possible, there will be much more detail
:about how to do the conversion, as well as the working examples of the
:first drivers to be converted.

    I believe I found a way to isolate the legacy spl*() stuff without too 
    much interference with the overall design plan (see my document), but
    I will be the second to say that the legacy stuff is ALL going to be
    ripped out for the 5.0 release.

    I would ask that people not commit major changes to the -current sys tree
    until after we lay down the tags and get the new MP core in place.

					-Matt
					Matthew Dillon 
					<dil...@backplane.com>

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Jason Evans <jas...@canonware.com>
Subject: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
Date: 2000/06/20
Message-ID: <fa.hr7kcov.1r1m90o@ifi.uio.no>#1/1
Original-Date: Mon, 19 Jun 2000 18:01:14 -0700
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-ID: <20000619180113.G79318@blitz.canonware.com>
References: <fa.kja131v.1e78ha5@ifi.uio.no>
To: Matthew Dillon <dil...@apollo.backplane.com>
Original-References: <20000619115330.D79...@blitz.canonware.com> <200006200034.RAA81...@apollo.backplane.com>
Content-Type: text/plain; charset=us-ascii
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.freebsd.current

On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
>     Ok, I have put up a web page that will track my efforts.
> 
> 	http://apollo.backplane.com/FreeBSDSmp/

On this page, you say:

  The algorithms described on this page are essentially the BSDI algorithms
  plus accomodations we disussed at the Yahoo SMP meeting. However, I did
  not do a direct port. I did a from-scratch rewrite because, simply put,
  it was easier for me. The variables are named differently but I attempt
  to follow the same API. All the work is subject to change... the point is
  to make it work first, then clean it up later.

Does this include the locking primitives?  In the case of the locking
primitives, there is functionality that we definitely need, such as the
witness code, and it probably would save effort to use the BSD/OS code.
I'm guessing that you are actually using the BSD/OS code in this case; I'm
just looking for clarification.

Thanks,
Jason

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
Date: 2000/06/20
Message-ID: <fa.kgq70iv.1cnejq8@ifi.uio.no>#1/1
Original-Date: Mon, 19 Jun 2000 18:12:40 -0700 (PDT)
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-Id: <200006200112.SAA82090@apollo.backplane.com>
References: <fa.hr7kcov.1r1m90o@ifi.uio.no>
To: Jason Evans <jas...@canonware.com>
Original-References: <20000619115330.D79...@blitz.canonware.com> <200006200034.RAA81...@apollo.backplane.com> <20000619180113.G79...@blitz.canonware.com>
Organization: Internet mailing list
Newsgroups: fa.freebsd.current

:On this page, you say:
:
:  The algorithms described on this page are essentially the BSDI algorithms
:  plus accomodations we disussed at the Yahoo SMP meeting. However, I did
:  not do a direct port. I did a from-scratch rewrite because, simply put,
:  it was easier for me. The variables are named differently but I attempt
:  to follow the same API. All the work is subject to change... the point is
:  to make it work first, then clean it up later.
:
:Does this include the locking primitives?  In the case of the locking
:primitives, there is functionality that we definitely need, such as the
:witness code, and it probably would save effort to use the BSD/OS code.
:I'm guessing that you are actually using the BSD/OS code in this case; I'm
:just looking for clarification.
:
:Thanks,
:Jason

    The API is very similar, and when I clean it up it should be possible
    to make it exactly the same, but SPL/CPL/INTERRUPT considerations 
    make using the BSDI code verbatim impossible.

    Basically I rewrote the core mutex code but I used *everything* that
    was discussed at the meeting in the implementation, so all the features
    that we need are there.  Spin locks, blocking locks, Giant lock
    save/restore integrated into the scheduler, quick-attempt in an
    inline then a call to a real procedure if it fails, using the low 2
    bits of the mutex lock field to implement a 'held' bit and a 'contested'
    bit (which works really wonderfully, I might add!  I would never have
    thought of doing things that way myself!).

    I am trying to keep it close enough that we can add the witness code
    in, but before I do that I want to get the system semi-stable.
    In some respects it's actually easier for us with FreeBSD
    because we are keeping the spl*() system intact for a while.

    The witness code is going to be critical for the unwinding work (moving
    things out of the Giant mutex and into their own mutexes).  It isn't
    critical for this first stage which basically just puts everything
    under the Giant lock and doesn't *have* any other mutexes beyond 
    SchedMutex and GiantMutex.

					-Matt
					Matthew Dillon 
					<dil...@backplane.com>



To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Poul-Henning Kamp <p...@critter.freebsd.dk>
Subject: Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development) 
Date: 2000/06/20
Message-ID: <fa.jn24cav.a70fov@ifi.uio.no>#1/1
Original-Date: Tue, 20 Jun 2000 09:41:57 +0200
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-ID: <51028.961486917@critter.freebsd.dk>
References: <fa.hr7kcov.1r1m90o@ifi.uio.no>
To: Jason Evans <jas...@canonware.com>
Organization: Internet mailing list
Newsgroups: fa.freebsd.current


Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?

Can we get to see the slides ?

Audio ?

Video ?

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Warner Losh <i...@village.org>
Subject: Re: HEADS UP: Destabilization due to SMP development 
Date: 2000/06/20
Message-ID: <fa.i44cn1v.1n22hal@ifi.uio.no>#1/1
Original-Date: Tue, 20 Jun 2000 12:33:21 -0600
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-Id: <200006201833.MAA70626@harmony.village.org>
References: <fa.hs70e0v.1q1288p@ifi.uio.no>
To: Jason Evans <jas...@canonware.com>
Original-References: <20000619115330.D79...@blitz.canonware.com>  
Organization: Internet mailing list
Newsgroups: fa.freebsd.current

In message <20000619115330.D79...@blitz.canonware.com> Jason Evans writes:
: Summary: -current will be destabilized for an extended period (on the order
: of months).  A tag (not a branch) will be laid down before the initial
: checkin, and non-developers should either stick closely to that tag until
: the kernel stabilizes, or expect large doses of pain.  This tag will be
: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
: beforehand.

Thanks for the fair warning.  Now don't do it.  Has core approved
this?  I don't think so, I've seen nothign from them about it.

The instability ni -current for MONTHS is pain not acceptible.  We've
never really allowed that in the past.  A CVS branch would be mcuh
better for this sort of thing.  I know that's a pain as well, but this 
is just for SMP people and the rest of us shouldn't have to deal with
the pain.

I understand your desire to have it all in a working tree, but causing
pain for ALL developers for potentially MONTHS isn't a reasonable
request.

Warner

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Poul-Henning Kamp <p...@critter.freebsd.dk>
Subject: Re: HEADS UP: Destabilization due to SMP development 
Date: 2000/06/20
Message-ID: <fa.jlimciv.cn6cgr@ifi.uio.no>#1/1
Original-Date: Tue, 20 Jun 2000 20:49:27 +0200
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-ID: <54765.961526967@critter.freebsd.dk>
References: <fa.i44cn1v.1n22hal@ifi.uio.no>
To: Warner Losh <i...@village.org>
Organization: Internet mailing list
Newsgroups: fa.freebsd.current

In message <200006201833.MAA70...@harmony.village.org>, Warner Losh writes:
>In message <20000619115330.D79...@blitz.canonware.com> Jason Evans writes:
>: Summary: -current will be destabilized for an extended period (on the order
>: of months).  A tag (not a branch) will be laid down before the initial
>: checkin, and non-developers should either stick closely to that tag until
>: the kernel stabilizes, or expect large doses of pain.  This tag will be
>: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
>: beforehand.
>
>Thanks for the fair warning.  Now don't do it.  Has core approved
>this?  I don't think so, I've seen nothign from them about it.

I think core has approved in principle, and several core members
were present at the meeting (at least peter, dg, gibbs, dfr), that
being said, I think we need to see some more concrete info before
we pull the lever, just so we know what to expect.

>The instability ni -current for MONTHS is pain not acceptible.

Sorry, Warner, but progress has its price, and this may be it.

>I understand your desire to have it all in a working tree, but causing
>pain for ALL developers for potentially MONTHS isn't a reasonable
>request.

I belive the only viable alternative, as CVS branches are generally
agreed to be >= 25 megasuckage caliber, is to switch the project
to use Perforce.

Until now at least, we have not done that, because developing open
source with a closed source tool has been too much taboo for us
to bother, and it would (as far as we know) not work with cvsup.

I'm not sure now is the time to do it either.

So:  No I don't like -current being toast anymore than you do, but
I don't think there is a viable alternative.

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Warner Losh <i...@village.org>
Subject: Re: HEADS UP: Destabilization due to SMP development 
Date: 2000/06/20
Message-ID: <fa.i34em1v.1m20hag@ifi.uio.no>#1/1
Original-Date: Tue, 20 Jun 2000 12:57:41 -0600
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-Id: <200006201857.MAA71034@harmony.village.org>
References: <fa.jlimciv.cn6cgr@ifi.uio.no>
To: Poul-Henning Kamp <p...@critter.freebsd.dk>
Original-References: <54765.961526...@critter.freebsd.dk>  
Organization: Internet mailing list
Newsgroups: fa.freebsd.current

In message <54765.961526...@critter.freebsd.dk> Poul-Henning Kamp writes:
: I think core has approved in principle, and several core members
: were present at the meeting (at least peter, dg, gibbs, dfr), that
: being said, I think we need to see some more concrete info before
: we pull the lever, just so we know what to expect.

I'd like to see an explicit vote saying that current can be broken for 
months for SP users so the MP work can go in.  It has often been said
that individual core members do not speak for core.

: >The instability ni -current for MONTHS is pain not acceptible.
: 
: Sorry, Warner, but progress has its price, and this may be it.

I don't think so.  I've done all the NEWCARD work in the tree, and it
hasn't broken anything else (at least not for more than a few hours
when I screwed up).  It has been painful for me to do it that way, but
I think that some consideration should be given for the transition
period for SP users.

A few days or weeks I don't have a prblem with, but a few months is
flat not acceptible.  It is too long.  If the code is that green, then
some other mechanism needs to be used to facilitate collaberative
working.

I'd rather see a firm deadline proposed (eg, we'll commit the core on
June 26, and will be done by Aug 26) so that I know what to expect
rather than having the nebulous a few months phrase kicked around.  I
expected the newcard stuff to be working in a few months, and it has
been about 8 so far.

: So:  No I don't like -current being toast anymore than you do, but
: I don't think there is a viable alternative.

Sure we do.  They get their patches together, and commit them once
they will cuase less pain.  There's always alternatives.  The issue
here is who has to live with the pain.

The MP guys could easily use perforce for this and then merge once
things are stabilized enough to not impact SP people to the point that 
things won't be usable.  The cam folks did this in the past, and it
worked fairly well.

Also, what if the new MP core goes in and one or more of the key
players all of a sudden have no time to finish this due to unforseen
circumstances?  Will the tree remain broken while they sort this out?

Again, I dont' want to hold up progress, but saying that it must be
done this way and I have to put up with it for the sake of progerss is 
not a good justification.

Warner

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: HEADS UP: Destabilization due to SMP development 
Date: 2000/06/20
Message-ID: <fa.klql31v.18m8haa@ifi.uio.no>#1/1
Original-Date: Tue, 20 Jun 2000 12:20:29 -0700 (PDT)
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-Id: <200006201920.MAA87999@apollo.backplane.com>
References: <fa.i44cn1v.1n22hal@ifi.uio.no>
To: Warner Losh <i...@village.org>
Original-References: <20000619115330.D79...@blitz.canonware.com>   <200006201833.MAA70...@harmony.village.org>
Organization: Internet mailing list
Newsgroups: fa.freebsd.current

:: the kernel stabilizes, or expect large doses of pain.  This tag will be
:: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
:: beforehand.
:
:Thanks for the fair warning.  Now don't do it.  Has core approved
:this?  I don't think so, I've seen nothign from them about it.
:
:The instability ni -current for MONTHS is pain not acceptible.  We've
:never really allowed that in the past.  A CVS branch would be mcuh
:better for this sort of thing.  I know that's a pain as well, but this 
:is just for SMP people and the rest of us shouldn't have to deal with
:the pain.
:
:I understand your desire to have it all in a working tree, but causing
:pain for ALL developers for potentially MONTHS isn't a reasonable
:request.
:
:Warner

    The problem is that the changes are simply too extensive to be able
    be able to split them off then merge them back into 5.x N months later.
    Creating another branch will tripple the workload on anyone doing 
    merge work.

    We knew we'd probably have to do it this way months ago, and Chuck
    Paterson of BSDI confirmed it when he related his experiences with
    trying to manage the BSDI 5.x MP stuff as a separate branch.
    In short, it was a complete disaster, and I have no doubts that
    trying to manage it as a separate branch in FreeBSD would also result
    in a complete disaster.

    We've known this day was coming for ages... ever since Jordan announced
    the BSDI merger.  Jordan and other core members have hinted, intimated,
    and outright told people that FreeBSD-current would be used for the BSDI
    merge work.  Well, the time is now folks!

					-Matt
					Matthew Dillon 
					<dil...@backplane.com>

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Warner Losh <i...@village.org>
Subject: Re: HEADS UP: Destabilization due to SMP development 
Date: 2000/06/20
Message-ID: <fa.i1kim9v.1ki4hih@ifi.uio.no>#1/1
X-Deja-AN: 636920944
Original-Date: Tue, 20 Jun 2000 13:27:03 -0600
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-Id: <200006201927.NAA71421@harmony.village.org>
References: <fa.i44cn1v.1n22hal@ifi.uio.no>
To: Matthew Dillon <dil...@apollo.backplane.com>
Original-References: <200006201920.MAA87...@apollo.backplane.com>  <20000619115330.D79...@blitz.canonware.com> <200006201833.MAA70...@harmony.village.org> 
Delivered-To: freebsd-curr...@freebsd.org
Organization: Internet mailing list
Newsgroups: fa.freebsd.current
X-Loop: FreeBSD.ORG

In message <200006201920.MAA87...@apollo.backplane.com> Matthew Dillon writes:
:     The problem is that the changes are simply too extensive to be able
:     be able to split them off then merge them back into 5.x N months later.
:     Creating another branch will tripple the workload on anyone doing 
:     merge work.

One could argue that you could merge the changes to FreeBSD 5.X on a
daily or weekly basis to that branch so that the branch doesn't get
too far out of what.  Perforce users do this all the time (cf the cam
project).  The model that I see is that a branch is created for SMP
work, and that you find a volunteer who has access to SMP machines who 
will merge from current into the SMP branch once a week and boot the
resulting kernel.  If it works, he commits it, otherwise he resovles
the problems.  That way the main developers aren't significantly
impacted by the merging.

I'd be a lot happier if there was an upper bound on the length of time 
that -current would be unstable, if there was a plan in place on what
to do if that timelimit was exceeded, if there was a roadmap I could
look at, etc.  Right now the vagueness of it all pushes my panic
button.  I'm trying to get more information so that I know if I should 
just calm down and it won't be that bad, or if I should pitch a huge
fit because it will be too painful to make progress on any other
front.  Please help me with that.

I'd also be happy if I could create a newcard branch off the last
stable version of freebsd 5.0-current.  That way I could continue my
work with others and the instability wouldn't matter.  All merging, if 
any, would be my responsibility.  I don't know what the level of pain 

Of course the same arugment about merging you make could be made for
new kernel work.  They will either have to live with the pain (which
is currently ill-defined at best, knowing what the pain would be would 
help my confort level), or do their work and then redo it on the new
and improved FreeBSD months later.  Why should SMP force others to do
that?

Warner

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Jason Evans <jas...@canonware.com>
Subject: Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
Date: 2000/06/21
Message-ID: <fa.krfeeiv.t66k2o@ifi.uio.no>#1/1
X-Deja-AN: 637123709
Original-Date: Wed, 21 Jun 2000 00:41:20 -0700
Sender: owner-freebsd-curr...@FreeBSD.ORG
Original-Message-ID: <20000621004120.G233@blitz.canonware.com>
References: <fa.jn24cav.a70fov@ifi.uio.no>
To: Poul-Henning Kamp <p...@critter.freebsd.dk>
Original-References: <20000619180113.G79...@blitz.canonware.com> <51028.961486...@critter.freebsd.dk>
Delivered-To: freebsd-curr...@freebsd.org
Content-Type: text/plain; charset=us-ascii
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.freebsd.current
X-Loop: FreeBSD.ORG

On Tue, Jun 20, 2000 at 09:41:57AM +0200, Poul-Henning Kamp wrote:
> 
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?

I'm at USENIX right now, so I'm a bit strapped for time to work on this.
Still, I plan to email a brief summary of the meeting within the next
couple of days.  It won't include all of the gory details, simply because I
don't remember all of them(my notes were mainly for my own benefit, and are
of limited usefulness).

> Can we get to see the slides ?

I have the slides, but need to get them on a web page.  This will also
happen in the next couple of days.

> Audio ?
> 
> Video ?

Greg Lehey has a PAL recording of much of the meeting.  If you want to get
ahold of a copy, talk to him privately to see what arrangements you can
make.

Jason

To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Greg Lehey <g...@lemis.com>
Subject: Re: SMP locking primities (was Re: HEADS UP: Destabilization due to SMP development)
Date: 2000/06/21
Message-ID: <fa.n84t9mv.1pks3av@ifi.uio.no>#1/1
X-Deja-AN: 637266949
Original-Date: Tue, 20 Jun 2000 23:36:05 -0700
Sender: owner-freebsd-curr...@FreeBSD.ORG
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Original-Message-ID: <20000620233605.C308@sydney.worldwide.lemis.com>
References: <fa.jn24cav.a70fov@ifi.uio.no>
To: Poul-Henning Kamp <p...@critter.freebsd.dk>
Original-References: <20000619180113.G79...@blitz.canonware.com> <51028.961486...@critter.freebsd.dk>
Delivered-To: freebsd-curr...@freebsd.org
WWW-Home-Page: http://www.lemis.com/~grog
Content-Type: text/plain; charset=us-ascii
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Mobile: +61-418-838-708
Phone: +61-8-8388-8286
Mime-Version: 1.0
Newsgroups: fa.freebsd.current
X-Loop: FreeBSD.ORG
Fax: +61-8-8388-8725

On Tuesday, 20 June 2000 at  9:41:57 +0200, Poul-Henning Kamp wrote:
>
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?

I'm writing up a detailed trip report for my company.  I can't see why
I shouldn't forward it to the SMP list as well, but I suppose I should
check.

> Can we get to see the slides ?

Chuck Patterson has some.  I'm sure we could get him to send the
.pdf's.

> Audio ?

No.

> Video ?

Very patchy.  I started taping about 3 hours into the meeting, and
since I had better things to do than be cameraman, from time to time
we ran out of tape.  I'll make copies when I get back home.  On the
positive side, it's PAL.  But Apple has promised to make an NTSC
conversion.

Greg
--
Finger g...@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message

From: Greg Lehey <g...@lemis.com>
Subject: Re: HEADS UP: Destabilization due to SMP development
Date: 2000/06/21
Message-ID: <fa.n8539uv.1pk62io@ifi.uio.no>#1/1
X-Deja-AN: 637267104
Original-Date: Tue, 20 Jun 2000 23:47:08 -0700
Sender: owner-freebsd-curr...@FreeBSD.ORG
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Original-Message-ID: <20000620234708.E308@sydney.worldwide.lemis.com>
References: <fa.i34em1v.1m20hag@ifi.uio.no>
To: Warner Losh <i...@village.org>
Original-References: <54765.961526...@critter.freebsd.dk> <200006201857.MAA71...@harmony.village.org>
Delivered-To: freebsd-curr...@freebsd.org
WWW-Home-Page: http://www.lemis.com/~grog
Content-Type: text/plain; charset=us-ascii
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Mobile: +61-418-838-708
Phone: +61-8-8388-8286
Mime-Version: 1.0
Newsgroups: fa.freebsd.current
X-Loop: FreeBSD.ORG
Fax: +61-8-8388-8725

On Tuesday, 20 June 2000 at 12:57:41 -0600, Warner Losh wrote:
> In message <54765.961526...@critter.freebsd.dk> Poul-Henning Kamp writes:
>>  I think core has approved in principle, and several core members
>>  were present at the meeting (at least peter, dg, gibbs, dfr), that
>>  being said, I think we need to see some more concrete info before
>>  we pull the lever, just so we know what to expect.
>
> I'd like to see an explicit vote saying that current can be broken for
> months for SP users so the MP work can go in.  It has often been said
> that individual core members do not speak for core.

I'm quite happy to accept a majority vote of -core.

>>> The instability ni -current for MONTHS is pain not acceptible.
>>
>>  Sorry, Warner, but progress has its price, and this may be it.
>
> I don't think so.  I've done all the NEWCARD work in the tree, and it
> hasn't broken anything else (at least not for more than a few hours
> when I screwed up).  It has been painful for me to do it that way, but
> I think that some consideration should be given for the transition
> period for SP users.
>
> A few days or weeks I don't have a prblem with, but a few months is
> flat not acceptible.  It is too long.  If the code is that green, then
> some other mechanism needs to be used to facilitate collaberative
> working.
>
> I'd rather see a firm deadline proposed (eg, we'll commit the core on
> June 26, and will be done by Aug 26) so that I know what to expect
> rather than having the nebulous a few months phrase kicked around.  I
> expected the newcard stuff to be working in a few months, and it has
> been about 8 so far.

This was one of the points we discussed.  I was very much in favour of
a longer period so that people like you could commit their changes.
On the other hand, I think that the breakage will be relative, and it
will be less for SP systems than for SMP systems.  Certainly I think
that Matt and I need to get our act together (i.e. a system which at
least limps) before we commit anything; possibly people were a little
too optimistic about how quickly we could do things when we broke up
on Friday.

> Also, what if the new MP core goes in and one or more of the key
> players all of a sudden have no time to finish this due to unforseen
> circumstances?  Will the tree remain broken while they sort this
> out?

Maybe.  It depends on the circumstances and the preparedness of others
to fix it.  But I do think that we're entering a new phase of software
development with this project: for the first time we have a project
manager (Jason Evans), and I'd expect him to drum up some support,
from BSDi if necessary.  Note that Chuck Patterson is slated to help
us with 50% of his working time until we get this rickety framework to
fly.

Greg
--
Finger g...@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majord...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message