document:
Christoph Hellwig <hch@infradead.org>
Arjan van de Ven <arjanv@redhat.com>
- Randy Dunlap <rddunlap@osdl.org>
+ Randy Dunlap <rdunlap@xenotime.net>
Andre Hedrick <andre@linux-ide.org>
The following people helped with fixes/contributions to the bio patches
limit. No highmem default.
blk_queue_max_sectors(q, max_sectors)
- Maximum size request you can handle in units of 512 byte
- sectors. 255 default.
+ Sets two variables that limit the size of the request.
+
+ - The request queue's max_sectors, which is a soft size in
+ units of 512 byte sectors, and could be dynamically varied
+ by the core kernel.
+
+ - The request queue's max_hw_sectors, which is a hard limit
+ and reflects the maximum size request a driver can handle
+ in units of 512 byte sectors.
+
+ The default for both max_sectors and max_hw_sectors is
+ 255. The upper limit of max_sectors is 1024.
blk_queue_max_phys_segments(q, max_segments)
Maximum physical segments you can handle in a request. 128
The generic i/o scheduler would make sure that it places the barrier request and
all other requests coming after it after all the previous requests in the
queue. Barriers may be implemented in different ways depending on the
-driver. A SCSI driver for example could make use of ordered tags to
-preserve the necessary ordering with a lower impact on throughput. For IDE
-this might be two sync cache flush: a pre and post flush when encountering
-a barrier write.
-
-There is a provision for queues to indicate what kind of barriers they
-can provide. This is as of yet unmerged, details will be added here once it
-is in the kernel.
+driver. For more details regarding I/O barriers, please read barrier.txt
+in this directory.
1.2.2 Request Priority/Latency
blk_queue_invalidate_tags(request_queue_t *q)
- Clear the internal block tag queue and readd all the pending requests
+ Clear the internal block tag queue and re-add all the pending requests
to the request queue. The driver will receive them again on the
next request_fn run, just like it did the first time it encountered
them.
Kvec i/o:
- Ben LaHaise's aio code uses a slighly different structure instead
+ Ben LaHaise's aio code uses a slightly different structure instead
of kiobufs, called a kvec_cb. This contains an array of <page, offset, len>
tuples (very much like the networking code), together with a callback function
and data pointer. This is embedded into a brw_cb structure when passed
for a queue.
4.2 Request flows seen by I/O schedulers
-All requests seens by I/O schedulers strictly follow one of the following three
+All requests seen by I/O schedulers strictly follow one of the following three
flows.
set_req_fn ->
4.4 I/O contexts
I/O contexts provide a dynamically allocated per process data area. They may
be used in I/O schedulers, and in the block layer (could be used for IO statis,
-priorities for example). See *io_context in drivers/block/ll_rw_blk.c, and
-as-iosched.c for an example of usage in an i/o scheduler.
+priorities for example). See *io_context in block/ll_rw_blk.c, and as-iosched.c
+for an example of usage in an i/o scheduler.
5. Scalability related changes
and Linus' comments - Jan 2001)
9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan
et al - Feb-March 2001 (many of the initial thoughts that led to bio were
-brought up in this discusion thread)
+brought up in this discussion thread)
9.3 Discussions on mempool on lkml - Dec 2001.