| /freebsd/sys/vm/ |
| H A D | vm_map.h | diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
|
| H A D | vm_glue.c | diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
|
| H A D | vm_fault.c | diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
|
| H A D | vm_pageout.c | diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
|
| H A D | vm_map.c | diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
diff 25adb370bec8a0768af7dffa365e319c2fac3f04 Mon Mar 18 16:08:09 CET 2002 Brian Feldman <green@FreeBSD.org> Back out the modification of vm_map locks from lockmgr to sx locks. The
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
|