#
343329 |
|
23-Jan-2019 |
mav |
MFC r342400: Increase MTX_POOL_SLEEP_SIZE from 128 to 1024.
This value remained unchanged for 15 years, and now this bump reduces lock spinning in GEOM and BIO layers while doing ~1.6M IOPS to 4 NVMe on 72-core system from ~25% to ~5% by the cost of additional 28KB RAM.
While there, align struct mtx_pool fields to cache lines.
|
#
265216 |
|
02-May-2014 |
rwatson |
Garbage collect mtxpool_lockbuilder, the mutex pool historically used for lockmgr and sx interlocks, but unused since optimised versions of those sleep locks were introduced. This will save a (quite) small amount of memory in all kernel configurations. The sleep mutex pool is retained as it is used for 'struct bio' and several other consumers.
Discussed with: jhb MFC after: 3 days
|
#
117494 |
|
12-Jul-2003 |
truckman |
Extend the mutex pool implementation to permit the creation and use of multiple mutex pools with different options and sizes. Mutex pools can be created with either the default sleep mutexes or with spin mutexes. A dynamically created mutex pool can now be destroyed if it is no longer needed.
Create two pools by default, one that matches the existing pool that uses the MTX_NOWITNESS option that should be used for building higher level locks, and a new pool with witness checking enabled.
Modify the users of the existing mutex pool to use the appropriate pool in the new implementation.
Reviewed by: jhb
|
#
93818 |
|
04-Apr-2002 |
jhb |
Change callers of mtx_init() to pass in an appropriate lock type name. In most cases NULL is passed, but in some cases such as network driver locks (which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used.
Tested on: i386, alpha, sparc64
|
#
92246 |
|
13-Mar-2002 |
green |
Rename SI_SUB_MUTEX to SI_SUB_MTX_POOL to make the name at all accurate. While doing this, move it earlier in the sysinit boot process so that the VM system can use it.
After that, the system is now able to use sx locks instead of lockmgr locks in the VM system. To accomplish this, some of the more questionable uses of the locks (such as testing whether they are owned or not, as well as allowing shared+exclusive recursion) are removed, and simpler logic throughout is used so locks should also be easier to understand.
This has been tested on my laptop for months, and has not shown any problems on SMP systems, either, so appears quite safe. One more user of lockmgr down, many more to go :)
|