Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())

[Christoph Hellwig <hch@infradead.org>]

On Wed, Sep 28, 2011 at 12:05:10PM -0700, Eric Seppanen wrote:
> I agree: queue lock is the worst performance killer when hw can do
> >100K IOPS per block device.
> 
> Rather than just being chased away from the request queue due to
> performance issues, I could argue there's very little point to having
> a queue for devices that
> (a) have no seek penalty (and always use noop elevator)
> (b) have hardware queues at least as deep as the default request queue
> (c) don't benefit from merging
> 
> (c) is maybe debatable, but if a device can saturate its bus bandwidth
> on 4KB IO, the latency is probably not worth it.

In theory, yes.  But at some point we will be able to saturate them,
and then people want proportional I/O, light amounts of queueing, etc.

And I really don't want to reinvent that for every little device.  The
other problem is that we a single driver might driver totally different
types of devices, already today we have iSCSI or FC accessibly high
IOPS devices, there are good PCI-e flash devices masquerading as AHCI,
and my current problem is that the queue_lock really hurts me in
virtio-blk when using a PCIe flash device underneath.

So we really need some infrastructure that allows a generic interface
to the driver, and allow us to plug in merging, scheduling, queueing
on an as needed basis.

That is my long term plan - making request_lock suck a little less,
and improving the driver interface is a good first step, though.