sct@redhat.com said:
> There is a get-out for ext3 --- we can submit new journal IOs without
> waiting for the commit IO to complete, but hold back on writeback IOs.
> That still has the desired advantage of allowing us to stream to the
> journal, but only requires that the commit block be ordered with
> respect to older, not newer, IOs. That gives us most of the benefits
> of tagged queuing without any problems in your scenario.
Actually, I intended the tagged queueing discussion to be discouraging. The
amount of work that would have to be done to implement it is huge, touching,
as it does, every low level driver's interrupt routine. For the drivers that
require scripting changes to the chip engine, it's even worse: only someone
with specialised knowledge can actually make the changes.
It's feasible, but I think we'd have to demonstrate some quite significant
performance or other improvements before changes on this scale would fly.
Neither of you commented on the original suggestion. What I was wondering is
if we could benchmark (or preferably improve on) it:
James.Bottomley@SteelEye.com said:
> The easy way out of the problem, I think, is to impose the barrier as
> an effective queue plug in the SCSI mid-layer, so that after the
> mid-layer recevies the barrier, it plugs the device queue from below,
> drains the drive tag queue, sends the barrier and unplugs the device
> queue on barrier I/O completion.
If you need strict barrier ordering, then the queue is double plugged since
the barrier has to be sent down and waited for on its own. If you allow the
discussed permiability, the queue is only single plugged since the barrier can
be sent down along with the subsequent writes.
I can take a look at implementing this in the SCSI mid-layer and you could see
what the benchmark figures look like with it in place. If it really is the
performance pig it looks like, then we could go back to the linux-scsi list
with the tag change suggestions.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:43 EST