public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: linux-kernel@vger.kernel.org, akpm@zip.com.au, axboe@suse.de
Subject: Re: bio_chain: proposed solution for bio_alloc failure and large IO simplification
Date: Thu, 13 Jun 2002 20:24:38 -0600	[thread overview]
Message-ID: <20020614022438.GR682@clusterfs.com> (raw)
In-Reply-To: <200206140156.SAA02512@baldur.yggdrasil.com>

On Jun 13, 2002  18:56 -0700, Adam J. Richter wrote:
> 	2. bio_chain will set some kind of hint that newbio is
> probably contiguous with oldbio.  So, if oldbio is still on the
> device queue when newbio is eventually submitted, the merge code
> will first check the request that oldbio is in for merging.  So,
> the merging in that case will be O(1).

I really like this part of it.  I always disliked the fact that you
might have a large request at one layer that had to be split up for
submission, only to be re-merged later.  The fact that it could do
the merge in O(1) would be a good thing.

> 	Under this scheme, code that wants to build up big bio's
> can be much simpler, because it does not have to think about
> q->max_phys_segments or q->max_hw_segments (it just has to make sure
> that each request is smaller than q->max_sectors).

The recent discussions in this area have also been unsatisfying, and
this proposal works nicely to remove any knowledge of block device
specific limitations from the submitter.

If you are going to OLS this summer, there is a BOF related to
this "splitting BIO requests in the block layer" or something like
that.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


  reply	other threads:[~2002-06-14  2:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-14  1:56 bio_chain: proposed solution for bio_alloc failure and large IO simplification Adam J. Richter
2002-06-14  2:24 ` Andreas Dilger [this message]
2002-06-14 14:57 ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2002-06-14 16:52 Adam J. Richter
2002-06-14 23:00 ` Andrew Morton
2002-06-14 23:29   ` William Lee Irwin III
2002-06-14 23:38     ` Andrew Morton
2002-06-15  7:55 ` Jens Axboe
2002-06-14 23:39 Adam J. Richter
2002-06-14 23:58 ` Andrew Morton
2002-06-15  1:38   ` Oliver Xymoron
2002-06-15  7:55 ` Jens Axboe
2002-06-15  0:22 Adam J. Richter
2002-06-15  4:38 Adam J. Richter
2002-06-15  8:45 Adam J. Richter
2002-06-15  8:50 ` Jens Axboe
2002-06-15  8:52 Adam J. Richter
2002-06-15  9:00 ` Jens Axboe
2002-06-15  9:10 Adam J. Richter
2002-06-15  9:14 ` Jens Axboe
2002-06-15 10:30 Adam J. Richter
2002-06-15 19:50 ` Andrew Morton
2002-06-17  6:36   ` Jens Axboe
2002-06-17  7:09     ` Andrew Morton
2002-06-15 20:01 Adam J. Richter
2002-06-15 20:22 ` Andrew Morton
2002-06-15 20:24 Adam J. Richter
2002-06-17  6:37 ` Jens Axboe

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=20020614022438.GR682@clusterfs.com \
    --to=adilger@clusterfs.com \
    --cc=adam@yggdrasil.com \
    --cc=akpm@zip.com.au \
    --cc=axboe@suse.de \
    --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