tree 46603774141ec0eeec86a98d535b58e0270ebfc1
parent 4b593bc3a30e8b7241057ec853d6266bd3fc0e7f
author Barret Rhoden <brho@cs.berkeley.edu> 1593108110 -0400
committer Barret Rhoden <brho@cs.berkeley.edu> 1593108110 -0400

tests/linux: support multiple kernel lock tests

Just like userspace, we can now specify multiple tests to run in the
kernel.  It's basically the same as in userspace.

There are a few other fixups.  Notably:
- disable IRQs for multiple loops.  For whatever reason, disable/enable
IRQs (even outside the timestmping and critical section) hurts
performance (throughput and latency).  Just do it every so often.  Still
not 100% on this.

- hold_time is copied into the stack, instead of being global.  We could
also make it read_mostly - not sure if that would help.  The issue is
that it's often adjacent to other cache lines in the module.  Such as
the cache line holding the lock.  The adjacent cacheline prefetcher
*might* pull in that cacheline in exclusive mode.  That would cause all
threads to take a cache miss when reading hold_time.  You'd think that
grabbing the lock would always pull in hold_time for the lock holder,
but not necessarily.  It's an MCS lock, so you might have touched the
mcs_l a long time ago.  One reason why we wouldn't miss on hold_time
would be if we did READ_ONCE(lock_test) *before grabbing the lock*,
which would also pull in the cacheline.  That would only matter if the
AClP didn't always invalidate the line (which is true).  It's a mess.
Not 100% on this either.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>