Messages in this thread | | | Date | Fri, 25 Apr 2008 14:14:27 +0200 | From | Jens Axboe <> | Subject | Re: [RFC][PATCH 0/3] Skip I/O merges when disabled |
| |
On Fri, Apr 25 2008, Aaron Carroll wrote: > Jens Axboe wrote: > >>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. > > Front merging is probably a waste of time, but it could also be a hash table > lookup if you think the rbtree traversal is sinking too many cycles.
The front merges weren't considered important enough to add space for a seperate hash table, that is why they are (re)using the normal rb sort tree for lookups.
> I wonder if there's any merit in junking the merge hash (and > front-merging in the ioscheds proper) and just having per-process > one-hit caches. That's going to catch the majority of merge cases. > For requests that happen to be adjacent by chance, they are just as > likely to be back or front merges.
It's a possibility, the per-process plugging does that. The merge hash is fairly cheap though, so unless we ever merge the per-process plugging, I don't think it's a good idea to change it.
-- Jens Axboe
| |