I have the results from leaving in just the one-hit cache merge
attempts, and started a run leaving in both that and the back-merge
rq_hash checks. (The patch below basically undoes patch 3/3 - putting
back in the addition of rqs onto the hash list, and moves the nomerges
check below the back merge attempts.)
We /could/ change the tunable to a dial (or a mask) - enabling/disabling
specific merge attempts, but that seems a bit confusing/complex.
Jens: What do you think?
I think we should keep it simple. I don't particularly like having a
switch to toggle merges, no one will ever use it. So I'm more inclined
to just disable front merges unconditionally if the theory of where
the cycles are spent holds up. We'll still do front merges on the
one-hit cache, just not spend time looking up an io context and request
in the rbtree for basically no gain.