Messages in this thread |  | | Date | Thu, 5 Sep 2002 13:27:36 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: One more bio for for floppy users in 2.5.33.. |
| |
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/
|  |