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/- 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 Jun 15 2002 - 22:00:30 EST