linux-kernel - Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release

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: <20111130102643.GA2033@infradead.org>
Date:	Wed, 30 Nov 2011 05:26:43 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Eric Seppanen <eric@...estorage.com>,
	Christoph Hellwig <hch@...radead.org>,
	Vivek Goyal <vgoyal@...hat.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Hannes Reinecke <hare@...e.de>,
	James Bottomley <James.Bottomley@...allels.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue
 resources at blk_release_queue())

On Wed, Nov 30, 2011 at 11:18:42AM +0100, Jens Axboe wrote:
> I agree on a+b, but c is definitely more than debatable. I have yet to
> see a device saturate its bandwidth on 4KB IOS. So merging on the write
> side is always going to be a win.

We shouldn't submit 4k I/O in the first place unless they truely are
random.  If you look at XFS for example you'd basically never see them.
The only small I/O in a typical workloads are individual btree blocks
and AG header updates, which generally can't be merged anyway.  Data I/O
happens in larger chunks generally, as do reads/writes of inodes
(generally in 32k chunks, with plans to go larger).

Note that the merges in the way the are done currently are one of the
most painful bits of the current request_fn based drivers.  They require
the addition of the struct request data structure, which needs to be
allocated and initialized for every bio, no matter if it's beeing merged
or not, and are the prime reason why make_request_fn and request_fn
style drivers can't operate on the same data structures.

I've been wondering if it would be possible to simply chain bios for
merging, and while it's theoretically possible I'm wondering about
the impact on drivers.  Fortunately scsi drivers generally don't touch
struct request directly, so it might be doable.
--
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/