linux-kernel - Re: [RFC][PATCH 0/3] Skip I/O merges when disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080425121427.GR12774@kernel.dk>
Date:	Fri, 25 Apr 2008 14:14:27 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Aaron Carroll <aaronc@....unsw.edu.au>
Cc:	"Alan D. Brunelle" <Alan.Brunelle@...com>,
	linux-kernel@...r.kernel.org
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/