Re: Bio pool & scsi scatter gather pool usage

Denis Vlasenko (vda@port.imtp.ilyichevsk.odessa.ua)
Fri, 19 Apr 2002 13:44:53 -0200


On 18 April 2002 16:57, Andrew Morton wrote:
> > This would require the BIO assembly code to make at least one
> > call to find the current permissible BIO size at offset xyzzy.
> > Depending on the actual IO size many foo_max_bytes calls may
> > be required. Envision the LVM or RAID case where physical
> > extents or chunks sizes can be as small as 8Kb I believe. For
> > a 64Kb IO, its conceivable that 9 calls to foo_max_bytes may
> > be required to package that IO into permissibly sized BIOs.

[snip]

> The good way is:
>
> int maxbytes[something];
> int i = 0;
>
> while (more_to_send) {
> maxbytes[i] = bio_max_bytes(block);
> block += maxbytes[i++] / whatever;
> }
> i = 0;
> while (more_to_send) {
> build_and_send_a_bio(block, maxbytes[i]);
> block += maxbytes[i++] / whatever;
> }
>
> if you get my drift. This way the computational costs of
> the second and succeeding bio_max_bytes() calls are very
> small.

This has the advantage of being simple too.

> One thing which concerns me about the whole scheme at
> present is that the uncommon case (volume managers, RAID,
> etc) will end up penalising the common case - boring
> old ext2 on boring old IDE/SCSI.

Yes but since performance gap between CPU and devices
continue to increase simplicity outweights
CPU cycles wastage here. We are going to wait much longer
for IO to take place anyway.

> Right now, BIO_MAX_SECTORS is only 64k, and IDE can
> take twice that. I'm not sure what the largest
> request size is for SCSI - certainly 128k.

Yep, submitting largest possible block in one go is a win.

--
vda
-
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/