Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Nov 1999 11:58:47 -0800 (PST)
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Jonathon McKitrick <jcm@dogma.freebsd-uk.eu.org>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: threading and performance
Message-ID:  <Pine.BSF.4.05.9911081152060.12797-100000@fw.wintelcom.net>
In-Reply-To: <Pine.BSF.4.02A.9911081901310.6571-100000@dogma.freebsd-uk.eu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Nov 1999, Jonathon McKitrick wrote:

> On Mon, 8 Nov 1999, Alfred Perlstein wrote:
> 
> >yes, right now only one thread of execution can be active in
> >the kernel at any given time, this is going to change RSN.
> >
> >This really has very little to do with pthreads though.
> 
> -jonathon
> 
> RSN - Real Soon Now?

yes.

> Also, wouldn't this create bottlenecks when different processes have to
> wait for a single kernel thread to finish?  

yup part of the problem is determining where exactly to lock, how
to lock? spin? mutex? context switch? and how fine grained we want
to do it.

currenlt there is some locking support for long term exclusion such
as in the FS code, and TCP/IP stack, the problem is that the code
doesn't expect anything to be fiddling with kernel structures while
it's executing, it only expects that to happen if it potentially 
tsleeps, or it has asserted an spl level to protect itself from device
interrupts messing with variables.

> I think Solaris has
> multithreaded kernel support, IIRC.  I just find it so interesting that
> FBSD multitasks and context switches so efficiently and smoothly, and
> handles such heavy loads, yet the kernel is only single  threaded.  I just
> wondered how that was possible.  

The current BSD kernel locking model is quite effecient, solaris has all
this fine grained locking that kills performance until you go 8-way
SMP because not only are they finely grained with locking, they also
support pre-emption of kernel threads.  It's a nice feature but a
nightmare for performance because of all the additional locking and
retrys that must be done.

I think the direction we will head is fine grained locking but without
preemption of kernel threads, but that's still up for discussion.

> It's certainly a credit to the developers
> !  Frankly, if it works so well, you have to wonder if stability will be
> lost finding bugs in the new version if it has multi-threaded kernel
> support.  He, you can't make an omlette w/o breaking some eggs, right?

We don't plan on breaking anything. :)

-Alfred Perlstein - [bright@rush.net|alfred@freebsd.org]
Wintelcom systems administrator and programmer
   - http://www.wintelcom.net/ [bright@wintelcom.net]




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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911081152060.12797-100000>