hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
[20070208] Merging newlock2: consequences on in-kernel locking, SMP and threading
Andrew Doran has made substantial progress on the newlock2 branch, and he is now ready to merge the branch into NetBSD-current. Some of the changes this will bring are (citing from Andrew's mail, mostly):
  • A new set of synchronization primitives in the kernel designed to make programming for multiprocessor systems easier and more efficient: mutexes, reader / writer locks, condition variables, sleep queues and MI memory barrier operations.
  • A number of underlying kernel facilties have been made 'multiprocessor safe' including the scheduler, ktrace and the general purpose method of kernel synchronisation: sleep & wakeup
  • Some application facilities have been made MP safe and can now run without the "big lock" on multiprocessor systems, including signalling, SysV messaging, and system calls that inspect process state, for example: wait().
  • The number of system calls that will run without the big lock went from 1 up to 56, with more in the pipeline. For workloads that are fork intensive and make heavy use of signals this will show a small yet quantifiable benefit on multi-way systems.
  • The branch introduces a new 1:1 threading model that allows multithreaded applications to take advantage of all available CPUs in a multi-way system. The scheduler activations implementation used from NetBSD 2.0 through NetBSD 4.0 provides execellent performance on single CPU systems, but restricts any instance of a threaded application to a single CPU in the system. Given that multicore and multi-CPU systems are increasingly commonplace and that single threaded CPUs are rapidly disappearing from the market, we made the decision to move to a new threading model, on the basis that providing increased concurrency is now the most important factor in ensuring good performance for threaded workloads.
  • Those following source-changes already know what that new 1:1 threading model means for the scheduler-activations based m:n threading model: it's gone.
Read Andrew's mail for all the details, and esp. on how to update your system after the merge if you run -current!

[Tags: , , ]

Disclaimer: All opinion expressed here is purely my own. No responsibility is taken for anything.

Access count: 35358325
Copyright (c) Hubert Feyrer