mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: akpm@zip.com.au
Cc: axboe@suse.de, colpatch@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: Patch??: linux-2.5.20/fs/bio.c - ll_rw_kio could generate bio's bigger than queue could handle
Date: Fri, 7 Jun 2002 15:12:26 -0700	[thread overview]
Message-ID: <200206072212.PAA06870@adam.yggdrasil.com> (raw)

Andrew Morton wrote:
>+int bio_max_iovecs(request_queue_t *q, int *iovec_size)
>+{
>+       unsigned max_iovecs = min(q->max_phys_segments, q->max_hw_segments);

>It seems that this test will significantly reduce the max BIO
>size for some devices.  What's the thinking here?

	When you submit a bio with n iovecs, there is no guarantee
that any of those will have contiguous underlying physical addresses
or or that any of those addresses that can be made contiguous from the
view of a DMA device (most architectures lack an iommu anyhow, and
there is no guarantee that there would be enough entries available in
the iommu to do this, and I vaguely recal that existing iommu's have a
small number of entries, like 8 or 16).  This is true even when each
of the iovecs covers exactly one full page.

	Since there is no guarantee that any of these bios can be
merged in the general case, bio submitters have to ensure that
the number of IO vectors in each bio does not exeed q->max_phys_segments
*and* does not exceed q->max_hw_segments.  Otherwise, the request that
finally gets to the device driver may exceed the drivers capabilities.

	Of course, in cases where the bios happen to point to
physically contiguous memory, the request merging code will notice and
remerge the bios.  Since the bios generated from a big mpage or
ll_rw_kio call are already going to be pretty big, the overhead of the
bio merging code will be very small in proportion to the amount of
data being transferred.

	By the way, if you know something more about the block of
memory that you are writing, then you may be able to build bigger
bios.  For example, if you are writing a single contiguous range, then
you might be able to build bigger bios (limited by
q->max_segment_size, something that I should make bio_max_iovecs also
consider).

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

             reply	other threads:[~2002-06-07 22:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-07 22:12 Adam J. Richter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-06-07 22:46 Adam J. Richter
2002-06-07 12:46 Adam J. Richter
2002-06-07 16:52 ` Thunder from the hill
2002-06-07 20:19 ` Andrew Morton
2002-06-06 23:26 Adam J. Richter
2002-06-07  2:14 ` Andrew Morton
2002-06-06 13:31 Adam J. Richter
2002-06-06 19:34 ` Andrew Morton
2002-06-06 22:06 ` Matthew Dobson
2002-06-06  8:49 Adam J. Richter
2002-06-06  9:18 ` Andrew Morton
2002-06-06  1:22 Adam J. Richter
2002-06-06  1:48 ` Andrew Morton
2002-06-05 10:44 Adam J. Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200206072212.PAA06870@adam.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=akpm@zip.com.au \
    --cc=axboe@suse.de \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®