avoid lock contention in __thrsleep and __thrwakeup syscalls

turns out the __thrsleep and __thrwakeup syscalls largely coordinate
using a single lock per process. if you have heavily threaded code
building locks in userland out of thrsleep, this kernel lock gets
hammered. this is true even if userland thinks it's operating on
separate locks, it all ends up serialised in the kernel. this reduces
the throughput of these heavily threaded programs.

the big change is hashing thrsleep waiters into an different
locks/lists based on their "id" to try and avoid all locks in a
process contending on a single lock. the hash is shared by all
processes though.

the change also avoids having a waiter re-take the lock to avoid
contention on the thrwakeup code which is currently holding the lock.

__thrsleep and __thrwakeup seem to be largely unused these days,
except by go. go still uses it as a backend to it's locks, and also
creates a lot of threads which end up contending on the lock. these
changes provide an improvement for go programs.

the contention was pointed out by nick owens
jsing@ and nick owens did a bit of testing

0 files changed, 0 insertions, 0 deletions