:
:> ꀠ啱'm not sure where the concurrency is breaking down on the RAID subsystem,
:> ꀠ湶t could be due to that particular driver still being under the big
:> ꀠ淸iant lock (the AHCI and SILI drivers don't use the bgl, but arcmsr
:> ꀠ氽river probably still does).
:>
:
:arcmsr uses lockmgr and is not under the mplock at all. Which is not
:to say it isn't still serializing internally somewhere, but it should
:not be any different than FreeBSD in this regard.
:
:Sam
Hmm. There are two major locking points for a (CAM based) disk driver.
The first is the lock passed in cam_sim_alloc(). The second is whether
INTR_MPSAFE is passed to bus_setup_intr().
It looks like arcmsr is passing its own lock to cam_sim_alloc(), but
is *not* passing the INTR_MPSAFE flag to bus_setup_intr().
I haven't reviewed the interrupt handling code to determine how safe
the functions it calls internally are. arcmsr does get its own lock
in arcmsr_intr_handler(). It could very well be safe for us to set
the INTR_MPSAFE flag there but someone will have to life-test it.
In anycase, I'm not sure it's even the bottleneck for the earlier tests
since blockbench didn't run long enough (with default options) to use
up 32G of ram.
-Matt
Matthew Dillon
<dillon@backplane.com>