On Thu, 5 Sep 2002, Andrew Morton wrote:
>
> > - the code really cares about and uses the incremental information. At
> > which point it will already have "handled" any previous incremental
> > stuff, and the only thing it really cares about is the "new increment".
>
> So the BIO client would need to keep some state somewhere about "this is
> the next page to unlock". That would best be in the BIO somewhere.
Well, the information actually is there already, although I have to admit
that it's kind of subtle.
Look at the current mpage_end_io_read(), and realize that it already does
a traversal in pages from
start = bio->bi_io_vec
end = bio->bi_io_vec + bio->bi_vcnt - 1
which is actually very close to what it would do with partial results.
With partial results, it would need to do only a slightly different
traversal:
end = bio->bi_io_vec + bio->bi_vcnt*PAGE_SIZE - bio->bi_size
start = end - nr_sectors * 512
PAGE_ALIGN(start)
PAGE_ALIGN(end)
but it's otherwise the exact same code (doing all the edge calculations in
bytes, and then only traversing pages that have now been fully done and
weren't fully done last time).
It _looks_ like it literally needs just a few lines of changes.
So I would actually argue against adding new information: we _do_ actually
have the information already, and adding more "convenient" forms of it
adds more aliasing and coherency issues. The current form isn't _that_
complicated to use, and we might hide it behind a simple macro:
#define GET_PAGE_INDEXES(bio, start, end) \
... set start/end to point into the ...
... proper bio->bi_io_vec subarray ...
> Well we still will have the problem where reading 512 bytes from /dev/fd0
> does 64k of IO. That is most sweet for reading a bunch of 32k ext2 files
> from a hard drive, not so nice for reading fd0's partition table.
I do think we might make the read-ahead window configurable, and make slow
devices have slightly smaller windows.
On the other hand, I don't think the 64kB IO actually _hurts_ per se, as
long as it doesn't delay the stuff we care about.
Linus
-
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 Sep 07 2002 - 22:00:26 EST