/freebsd/sys/kern/ |
H A D | subr_turnstile.c | diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64 diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64
|
H A D | kern_mutex.c | diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64 diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64
|
/freebsd/sys/conf/ |
H A D | options | diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64 diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64
|
H A D | NOTES | diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64 diff 2498cf8c42924bdfa85da29e960a9467e32f872d Tue May 21 22:47:11 CEST 2002 John Baldwin <jhb@FreeBSD.org> Add code to make default mutexes adaptive if the ADAPTIVE_MUTEXES kernel option is used (not on by default).
- In the case of trying to lock a mutex, if the MTX_CONTESTED flag is set, then we can safely read the thread pointer from the mtx_lock member while holding sched_lock. We then examine the thread to see if it is currently executing on another CPU. If it is, then we keep looping instead of blocking. - In the case of trying to unlock a mutex, it is now possible for a mutex to have MTX_CONTESTED set in mtx_lock but to not have any threads actually blocked on it, so we need to handle that case. In that case, we just release the lock as if MTX_CONTESTED was not set and return. - We do not adaptively spin on Giant as Giant is held for long times and it slows SMP systems down to a crawl (it was taking several minutes, like 5-10 or so for my test alpha and sparc64 SMP boxes to boot up when they adaptively spinned on Giant). - We only compile in the code to do this for SMP kernels, it doesn't make sense for UP kernels.
Tested on: i386, alpha, sparc64
|