--nextPart2801878.nTUp2jrZUE
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 07 September 2005 9:15 pm, Matthew Orgass wrote:
> On 2005-09-06 ritter.alan@gmail.com wrote:
> > Anyway, It's not very difficult for me to add simplelock's to the code
> > for multiprocessor support, the difficult thing (I think) is that I
> > need to synchronize between the top and bottom halves of the kernel in
> > the same code.  For instance the same critical section may be ran in
> > multiple threads in the top half of the kernel (although I don't think
> > this is a problem as NetBSD kernel threads aren't scheduled), and it
> > might be ran without a user context.  I'm not sure if I need to
> > restructure the code so that functions which access shared data either
> > get called exclusively from the top half, or the bottom, but not both?
>
>   The spl call blocks the interrupt on the same processor to provide
> exclusion; this is what you should pay most attention to now.  As long as
> the code doesn't do anything that needs a process context it can then be
> run from both places.  The simple locks provide exclusion for
> multiprocessor systems, so you always want one just inside the spl
> protected area (inside so an interrupt on this processor doesn't try to
> acquire the same lock).  LOCKDEBUG on a single processor system can be
> very useful in making sure exclusion is really happening the way you
> think it is, so IMO locks are worth adding for SP systems.

OK, I added macros that raise the IPL, then grab a simple lock everyplace=20
there is synchronization required between the top and bottom halves

>   Lockmgr locks have significant additional cost but are useful when
> allowing multiple readers would help performance.  Context switching is
> expensive, so it is usually better to minimize time spent in the lock and
> use spin locks when possible.  Acquiring locks of any kind and spl
> operations are also fairly expensive; the more complex locks can help at
> times, just not with data you would want to access from interrupt
> context.

There were a lot of places I was using lockmgr locks that I removed, and th=
e=20
driver seems to work just the same (maybe a bit faster).  I originally just=
=20
replaced the freebsd mtx_lock(&lock) with lockmgr(&lock, LK_EXCLUSIVE,=20
NULL), and I tried removing this entirely.  This seemed to cause problems=20
however, so I put it back.  There are a few places in the FreeBSD code=20
where they do mtx_lock(&Giant), so I'm thinking I might need to use lockmgr=
=20
locks there.

Anyway, thanks for taking the time to explain this to me, it's been a big=20
help :-)

--nextPart2801878.nTUp2jrZUE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQBDIZMLdrBy3JhXjT8RAikHAJ9s9t0EtqRsPrQcOMXYEfEzg+PQvgCffE/v
QnMtKOEITux5EpSfRyLDvLQ=
=s8N0
-----END PGP SIGNATURE-----

--nextPart2801878.nTUp2jrZUE--