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.

  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.

Matthew Orgass
darkstar@city-net.com