[ On Saturday, June 15, 2002 at 10:59:06 (+0100), David Laight wrote: ]
> Subject: Re: Is the netBSD kernel Preemptible ?
>
> Eh? What evidence do you base that presumption on?
> The SMP ethernet driver (lance) driver I wrote would do concurrent
> TX setup on multiple CPUs.  Locks were only taken for a few
> instructions - eg grabbing a slot in the tx ring.

Yeah, setup's one thing, but there's still only one hardware interface
and just as you show above two CPUs can't diddle it at the same time
without getting in each other's way.  Logically a hardware device is
exactly the same as any other shared data structure.  It must be
accessed exclusively.  Many drivers are pretty lean so there's not very
much to split out and make reentrant so such preparation for I/O
operations can be done concurrently.

(of course the whole system's not that simple, and as shown in NYU's
Symunix-2's system, eg. through Jan Elder's disertation "Practical
Structures for Parallel Operating Systems", things get ever more complex
as the number of processors and devices goes up)

> > > Won't each driver need to lock/coordinate access?
> > 
> > Nope, not necessarily -- the system can put a separate semaphore around
> > each individual call.  If I'm not mistaken this is already effectively
> > done in NetBSD with simple_lock*() wrappers around the filesystem vnode
> > operations.  (I've not really been following NetBSD/SMP very closely yet
> > so I may be way off here!  ;-)
> 
> If you are doing this you have to use a single (or small number of)
> global locks.  You don't know which internal data structures a
> driver might access when entered to do a particular operation on a
> particular device.

Huh?  No well written driver will muck with stuff that's not also
properly protected via its own DDK interface.  Of course we don't have a
real DDK for NetBSD yet, but I think if you look at the code that's
there today you'll see it's nowhere near so coarse as you suggest it has
to be.  Even back two full years before the first full Block and
Character Interface Driver Reference Manual was published, Bach confirms
there wasn't any real problem with using a separate lock for every
driver.

> > To quote Bach and Buroff from the Oct. 1984 BSTJ again:
>
> Mmmmm  That seems to be talking about 'code locking' not 'data locking'
> The fact that it is so old (1984) makes me think it was written
> before any real SMP systems had been working.

Perhaps you should look a bit deeper at the history of UNIX.  The paper
I've been quoting from summarizes several _years_ of real-world
experience in Bell Labs at getting multi-processor systems running.  The
3B15 and 3B20A were real-world MP implementations.  Later WE32000 based
3B machines went from simple little two-CPU machines up to the massive
by comparison 3B4000.  The first report I know of about an AP UNIX
system was published in the fall of 1981 (Purdue's dual VAX).  IIRC the
MP work at the Labs started around that time.  You don't get numbers
about the throughput increase over single CPU systems (1.7 times)
without having a working system.

NYU's Master/Slave UNIX was running in 1983 too, and Elder turned it
into Symunix-1, which was more or less fully MP, by 1985.  It was
definitely "real" enough too!

MP UNIX is not an "new" thing by any stretch of the imagination -- it's
just that free implementations haven't had either cheap/commodity MP
hardware to run on, and/or support for development on high-end systems
until quite recently.

> Why do that!  nought wrong with sleep and wakeup - just implemement them
> MP safe - its not hard.

Go (re)read the BSTJ paper -- it's all in there.  Also (re)read chapter
12 of "The Design of the UNIX Operating System", Maurice Bach, Prentice
Hall, 1986, ISBN 0-13-201799-7.

(If you can't find a real copy of the Oct. 1984 BSTJ you can maybe find
a copy of the 1987 reprint by Prentice Hall, ISBN 0-13-939845-7)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>