Re: [PATCH 1/2] aio: add vectored I/O support

[Joel Becker]

On Sat, Oct 16, 2004 at 07:29:03PM +0200, Avi Kivity wrote:
> No. An iovec is already merged; it is known that adjacent segments of an 
> iovec have adjacent offsets. a single IO_CMD_READV iovec can generate a 
> single bio without any merging.

	A slightly embarrassed glance at the manpage later, I recall
that fact.  Something I never liked about writev(), but that's a moot
point.

> That's not what I meant. If you submit 16 iocbs which are merged by the 
> kernel, and there is an error somewhere within the seventh iocb, I would 
> expect to get 15 success completions and one error completion. so error 
> information from the merged iocb must be demultiplexed into the originals.

	This takes no effort, really, for the kernel.  The block layer
handles it.

> If you have a single iocb, then any error simply fails that iocb.

	True, but in some senses (and this is application specific) you
want to know that 15/16ths succeeded.  But we're talking about
application needs, not kernel design.  So it's moot for the technical
argument of whether READV is a useful operation.  I just wanted to have
the discussion.  It wasn't an objection per se.

> I think what happened was that the number of iocbs submitted (64 iocbs 
> of 4K each) did not merge because the device queue depth was very large; 
> no queuing occured because (I imagine) merging happens while a request 
> is waiting for disk readiness.

	Why did you submit 64 iocbs of 4K?  Was every page virtually
discontiguous, or did you arbitrarily decide to create a worst-case?

Joel

-- 

Life's Little Instruction Book #510

	"Count your blessings."

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