1.1 Tuning based on low level device / driver capabilities¶

Sophisticated devices with large built-in caches, intelligent i/o schedulingoptimizations, high memory DMA support, etc may find some of thegeneric processing an overhead, while for less capable devices thegeneric functionality is essential for performance or correctness reasons.Knowledge of some of the capabilities or parameters of the device should beused at the generic block layer to take the right decisions onbehalf of the driver.

How is this achieved ?

Tuning at a per-queue level:

1. Per-queue limits/values exported to the generic layer by the driver

Various parameters that the generic i/o scheduler logic uses are set ata per-queue level (e.g maximum request size, maximum number of segments ina scatter-gather list, logical block size)

Some parameters that were earlier available as global arrays indexed bymajor/minor are now directly associated with the queue. Some of these maymove into the block device structure in the future. Some characteristicshave been incorporated into a queue flags field rather than separate fieldsin themselves. There are blk_queue_xxx functions to set the parameters,rather than update the fields directly

Some new queue property settings:

blk_queue_bounce_limit(q, u64 dma_address)

Enable I/O to highmem pages, dma_address being thelimit. No highmem default.

blk_queue_max_sectors(q, max_sectors)

Sets two variables that limit the size of the request.

• The request queue’s max_sectors, which is a soft size inunits of 512 byte sectors, and could be dynamically variedby the core kernel.
• The request queue’s max_hw_sectors, which is a hard limitand reflects the maximum size request a driver can handlein units of 512 byte sectors.

The default for both max_sectors and max_hw_sectors is255. 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. 128default (driver limit). (See 3.2.2)

blk_queue_max_hw_segments(q, max_segments)

Maximum dma segments the hardware can handle in a request. 128default (host adapter limit, after dma remapping).(See 3.2.2)

blk_queue_max_segment_size(q, max_seg_size)

Maximum size of a clustered segment, 64kB default.

blk_queue_logical_block_size(q, logical_block_size)

Lowest possible sector size that the hardware can operateon, 512 bytes default.

New queue flags:

• QUEUE_FLAG_CLUSTER (see 3.2.2)
• QUEUE_FLAG_QUEUED (see 3.2.4)

2. High-mem i/o capabilities are now considered the default

The generic bounce buffer logic, present in 2.4, where the block layer wouldby default copyin/out i/o requests on high-memory buffers to low-memory buffersassuming that the driver wouldn’t be able to handle it directly, has beenchanged in 2.5. The bounce logic is now applied only for memory rangesfor which the device cannot handle i/o. A driver can specify this bysetting the queue bounce limit for the request queue for the device(blk_queue_bounce_limit()). This avoids the inefficiencies of the copyin/outwhere a device is capable of handling high memory i/o.

In order to enable high-memory i/o where the device is capable of supportingit, the pci dma mapping routines and associated data structures have now beenmodified to accomplish a direct page -> bus translation, without requiringa virtual address mapping (unlike the earlier scheme of virtual address-> bus translation). So this works uniformly for high-memory pages (whichdo not have a corresponding kernel virtual address space mapping) andlow-memory pages.

Note: Please refer toDynamic DMA mapping Guide for a discussionon PCI high mem DMA aspects and mapping of scatter gather lists, and supportfor 64 bit PCI.

Special handling is required only for cases where i/o needs to happen onpages at physical memory addresses beyond what the device can support. In thesecases, a bounce bio representing a buffer from the supported memory rangeis used for performing the i/o with copyin/copyout as needed depending onthe type of the operation. For example, in case of a read operation, thedata read has to be copied to the original buffer on i/o completion, so acallback routine is set up to do this, while for write, the data is copiedfrom the original buffer to the bounce buffer prior to issuing theoperation. Since an original buffer may be in a high memory area that’s notmapped in kernel virtual addr, a kmap operation may be required forperforming the copy, and special care may be needed in the completion pathas it may not be in irq context. Special care is also required (by way ofGFP flags) when allocating bounce buffers, to avoid certain highmemdeadlock possibilities.

It is also possible that a bounce buffer may be allocated from high-memoryarea that’s not mapped in kernel virtual addr, but within the range that thedevice can use directly; so the bounce page may need to be kmapped duringcopy operations. [Note: This does not hold in the current implementation,though]

There are some situations when pages from high memory may need tobe kmapped, even if bounce buffers are not necessary. For example a devicemay need to abort DMA operations and revert to PIO for the transfer, inwhich case a virtual mapping of the page is required. For SCSI it is alsodone in some scenarios where the low level driver cannot be trusted tohandle a single sg entry correctly. The driver is expected to perform thekmaps as needed on such occasions as appropriate. A driver could also usethe blk_queue_bounce() routine on its own to bounce highmem i/o to lowmemory for specific requests if so desired.

3. The i/o scheduler algorithm itself can be replaced/set as appropriate

As in 2.4, it is possible to plugin a brand new i/o scheduler for a particularqueue or pick from (copy) existing generic schedulers and replace/overridecertain portions of it. The 2.5 rewrite provides improved modularizationof the i/o scheduler. There are more pluggable callbacks, e.g for init,add request, extract request, which makes it possible to abstract specifici/o scheduling algorithm aspects and details outside of the generic loop.It also makes it possible to completely hide the implementation details ofthe i/o scheduler from block drivers.

I/O scheduler wrappers are to be used instead of accessing the queue directly.See section 4. The I/O scheduler for details.

1.2 Tuning Based on High level code capabilities¶

1. Application capabilities for raw i/o

This comes from some of the high-performance database/middlewarerequirements where an application prefers to make its own i/o schedulingdecisions based on an understanding of the access patterns and i/ocharacteristics

ii. High performance filesystems or other higher level kernel code’scapabilities

Kernel components like filesystems could also take their own i/o schedulingdecisions for optimizing performance. Journalling filesystems may needsome control over i/o ordering.

What kind of support exists at the generic block layer for this ?

The flags and rw fields in the bio structure can be used for some tuningfrom above e.g indicating that an i/o is just a readahead request, or prioritysettings (currently unused). As far as user applications are concerned theywould need an additional mechanism either via open flags or ioctls, or someother upper level mechanism to communicate such settings to block.

Arjan's proposed request priority scheme allows higher levels some broadcontrol (high/med/low) over the priority  of an i/o request vs other pendingrequests in the queue. For example it allows reads for bringing in anexecutable page on demand to be given a higher priority over pending writerequests which haven't aged too much on the queue. Potentially this prioritycould even be exposed to applications in some manner, providing higher leveltunability. Time based aging avoids starvation of lower priorityrequests. Some bits in the bi_opf flags field in the bio structure areintended to be used for this priority information.

1.3 Direct Access to Low level Device/Driver Capabilities (Bypass mode)¶

(e.g Diagnostics, Systems Management)

There are situations where high-level code needs to have direct access tothe low level device capabilities or requires the ability to issue commandsto the device bypassing some of the intermediate i/o layers.These could, for example, be special control commands issued through ioctlinterfaces, or could be raw read/write commands that stress the drive’scapabilities for certain kinds of fitness tests. Having direct interfaces atmultiple levels without having to pass through upper layers makesit possible to perform bottom up validation of the i/o path, layer bylayer, starting from the media.

The normal i/o submission interfaces, e.g submit_bio, could be bypassedfor specially crafted requests which such ioctl or diagnosticsinterfaces would typically use, and the elevator add_request routinecan instead be used to directly insert such requests in the queue or preferablythe blk_do_rq routine can be used to place the request on the queue andwait for completion. Alternatively, sometimes the caller might justinvoke a lower level driver specific interface with the request as aparameter.

If the request is a means for passing on special information associated withthe command, then such information is associated with the request->specialfield (rather than misuse the request->buffer field which is meant for therequest data buffer’s virtual mapping).

For passing request data, the caller must build up a bio descriptorrepresenting the concerned memory buffer if the underlying driver interpretsbio segments or uses the block layer end*request* functions for i/ocompletion. Alternatively one could directly use the request->buffer field tospecify the virtual address of the buffer, if the driver expects bufferaddresses passed in this way and ignores bio entries for the request typeinvolved. In the latter case, the driver would modify and manage therequest->buffer, request->sector and request->nr_sectors orrequest->current_nr_sectors fields itself rather than using the block layerend_request or end_that_request_first completion interfaces.(See 2.3 or Documentation/block/request.rst for a brief explanation ofthe request structure fields)

[TBD: end_that_request_last should be usable even in this case;Perhaps an end_that_direct_request_first routine could be implemented to makehandling direct requests easier for such drivers; Also for drivers thatexpect bios, a helper function could be provided for setting up a biocorresponding to a data buffer]<JENS: I dont understand the above, why is end_that_request_first() notusable? Or _last for that matter. I must be missing something><SUP: What I meant here was that if the request doesn't have a bio, then end_that_request_first doesn't modify nr_sectors or current_nr_sectors, and hence can't be used for advancing request state settings on the completion of partial transfers. The driver has to modify these fields directly by hand. This is because end_that_request_first only iterates over the bio list, and always returns 0 if there are none associated with the request. _last works OK in this case, and is not a problem, as I mentioned earlier>

2.1 Reason for a new structure and requirements addressed¶

Prior to 2.5, buffer heads were used as the unit of i/o at the generic blocklayer, and the low level request structure was associated with a chain ofbuffer heads for a contiguous i/o request. This led to certain inefficiencieswhen it came to large i/o requests and readv/writev style operations, as itforced such requests to be broken up into small chunks before being passedon to the generic block layer, only to be merged by the i/o schedulerwhen the underlying device was capable of handling the i/o in one shot.Also, using the buffer head as an i/o structure for i/os that didn’t originatefrom the buffer cache unnecessarily added to the weight of the descriptorswhich were generated for each such chunk.

The following were some of the goals and expectations considered in theredesign of the block i/o data structure in 2.5.

1. Should be appropriate as a descriptor for both raw and buffered i/o -avoid cache related fields which are irrelevant in the direct/page i/o path,or filesystem block size alignment restrictions which may not be relevantfor raw i/o.
2. Ability to represent high-memory buffers (which do not have a virtualaddress mapping in kernel address space).
3. Ability to represent large i/os w/o unnecessarily breaking them up (i.egreater than PAGE_SIZE chunks in one shot)
4. At the same time, ability to retain independent identity of i/os fromdifferent sources or i/o units requiring individual completion (e.g. forlatency reasons)
5. Ability to represent an i/o involving multiple physical memory segments(including non-page aligned page fragments, as specified via readv/writev)without unnecessarily breaking it up, if the underlying device is capable ofhandling it.
6. Preferably should be based on a memory descriptor structure that can bepassed around different types of subsystems or layers, maybe evennetworking, without duplication or extra copies of data/descriptor fieldsthemselves in the process
7. Ability to handle the possibility of splits/merges as the structure passesthrough layered drivers (lvm, md, evms), with minimal overhead.

The solution was to define a new structure (bio) for the block layer,instead of using the buffer head structure (bh) directly, the idea beingavoidance of some associated baggage and limitations. The bio structureis uniformly used for all i/o at the block layer ; it forms a part of thebh structure for buffered i/o, and in the case of raw/direct i/o kiobufs aremapped to bio structures.

2.2 The bio struct¶

The bio structure uses a vector representation pointing to an array of tuplesof <page, offset, len> to describe the i/o buffer, and has various otherfields describing i/o parameters and state that needs to be maintained forperforming the i/o.

Notice that this representation means that a bio has no virtual addressmapping at all (unlike buffer heads).

struct bio_vec {     struct page     *bv_page;     unsigned short  bv_len;     unsigned short  bv_offset;};/* * main unit of I/O for the block layer and lower layers (ie drivers) */struct bio {     struct bio          *bi_next;    /* request queue link */     struct block_device *bi_bdev;    /* target device */     unsigned long       bi_flags;    /* status, command, etc */     unsigned long       bi_opf;       /* low bits: r/w, high: priority */     unsigned int     bi_vcnt;     /* how may bio_vec's */     struct bvec_iter bi_iter;        /* current index into bio_vec array */     unsigned int     bi_size;     /* total size in bytes */     unsigned short   bi_hw_segments; /* segments after DMA remapping */     unsigned int     bi_max;      /* max bio_vecs we can hold                                      used as index into pool */     struct bio_vec   *bi_io_vec;  /* the actual vec list */     bio_end_io_t     *bi_end_io;  /* bi_end_io (bio) */     atomic_t         bi_cnt;      /* pin count: free when it hits zero */     void             *bi_private;};

With this multipage bio design:

• Large i/os can be sent down in one go using a bio_vec list consistingof an array of <page, offset, len> fragments (similar to the way fragmentsare represented in the zero-copy network code)
• Splitting of an i/o request across multiple devices (as in the case oflvm or raid) is achieved by cloning the bio (where the clone points tothe same bi_io_vec array, but with the index and size accordingly modified)
• A linked list of bios is used as before for unrelated merges[1] - thisavoids reallocs and makes independent completions easier to handle.
• Code that traverses the req list can find all the segments of a bioby using rq_for_each_segment. This handles the fact that a requesthas multiple bios, each of which can have multiple segments.
• Drivers which can’t process a large bio in one shot can use the bi_iterfield to keep track of the next bio_vec entry to process.(e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)[TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifyingbi_offset an len fields]

bi_end_io() i/o callback gets called on i/o completion of the entire bio.

At a lower level, drivers build a scatter gather list from the merged bios.The scatter gather list is in the form of an array of <page, offset, len>entries with their corresponding dma address mappings filled in at theappropriate time. As an optimization, contiguous physical pages can becovered by a single entry where <page> refers to the first page and <len>covers the range of pages (up to 16 contiguous pages could be covered thisway). There is a helper routine (blk_rq_map_sg) which drivers can use to buildthe sg list.

Note: Right now the only user of bios with more than one page is ll_rw_kio,which in turn means that only raw I/O uses it (direct i/o may not workright now). The intent however is to enable clustering of pages etc tobecome possible. The pagebuf abstraction layer from SGI also uses multi-pagebios, but that is currently not included in the stock development kernels.The same is true of Andrew Morton’s work-in-progress multipage bio writeoutand readahead patches.

2.3 Changes in the Request Structure¶

The request structure is the structure that gets passed down to low leveldrivers. The block layer make_request function builds up a request structure,places it on the queue and invokes the drivers request_fn. The driver makesuse of block layer helper routine elv_next_request to pull the next requestoff the queue. Control or diagnostic functions might bypass block and directlyinvoke underlying driver entry points passing in a specially constructedrequest structure.

Only some relevant fields (mainly those which changed or may be referredto in some of the discussion here) are listed below, not necessarily inthe order in which they occur in the structure (see include/linux/blkdev.h)Refer to Documentation/block/request.rst for details about all the requeststructure fields and a quick reference about the layers which aresupposed to use or modify those fields:

struct request {      struct list_head queuelist;  /* Not meant to be directly accessed by                                      the driver.                                      Used by q->elv_next_request_fn                                      rq->queue is gone                                      */      .      .      unsigned char cmd[16]; /* prebuilt command data block */      unsigned long flags;   /* also includes earlier rq->cmd settings */      .      .      sector_t sector; /* this field is now of type sector_t instead of int                          preparation for 64 bit sectors */      .      .      /* Number of scatter-gather DMA addr+len pairs after       * physical address coalescing is performed.       */      unsigned short nr_phys_segments;      /* Number of scatter-gather addr+len pairs after       * physical and DMA remapping hardware coalescing is performed.       * This is the number of scatter-gather entries the driver       * will actually have to deal with after DMA mapping is done.       */      unsigned short nr_hw_segments;      /* Various sector counts */      unsigned long nr_sectors;  /* no. of sectors left: driver modifiable */      unsigned long hard_nr_sectors;  /* block internal copy of above */      unsigned int current_nr_sectors; /* no. of sectors left in the                                         current segment:driver modifiable */      unsigned long hard_cur_sectors; /* block internal copy of the above */      .      .      int tag;        /* command tag associated with request */      void *special;  /* same as before */      char *buffer;   /* valid only for low memory buffers up to                       current_nr_sectors */      .      .      struct bio *bio, *biotail;  /* bio list instead of bh */      struct request_list *rl;}

See the req_ops and req_flag_bits definitions for an explanation of the variousflags available. Some bits are used by the block layer or i/o scheduler.

The behaviour of the various sector counts are almost the same as before,except that since we have multi-segment bios, current_nr_sectors refersto the numbers of sectors in the current segment being processed which couldbe one of the many segments in the current bio (i.e i/o completion unit).The nr_sectors value refers to the total number of sectors in the wholerequest that remain to be transferred (no change). The purpose of thehard_xxx values is for block to remember these counts every time it handsover the request to the driver. These values are updated by block onend_that_request_first, i.e. every time the driver completes a part of thetransfer and invokes block end*request helpers to mark this. Thedriver should not modify these values. The block layer sets up thenr_sectors and current_nr_sectors fields (based on the correspondinghard_xxx values and the number of bytes transferred) and updates it onevery transfer that invokes end_that_request_first. It does the same for thebuffer, bio, bio->bi_iter fields too.

The buffer field is just a virtual address mapping of the current segmentof the i/o buffer in cases where the buffer resides in low-memory. For highmemory i/o, this field is not valid and must not be used by drivers.

Code that sets up its own request structures and passes them down toa driver needs to be careful about interoperation with the block layer helperfunctions which the driver uses. (Section 1.3)

3.1 Setup/Teardown¶

There are routines for managing the allocation, and reference counting, andfreeing of bios (bio_alloc, bio_get, bio_put).

This makes use of Ingo Molnar’s mempool implementation, which enablessubsystems like bio to maintain their own reserve memory pools for guaranteeddeadlock-free allocations during extreme VM load. For example, the VMsubsystem makes use of the block layer to writeout dirty pages in order to beable to free up memory space, a case which needs careful handling. Theallocation logic draws from the preallocated emergency reserve in situationswhere it cannot allocate through normal means. If the pool is empty and itcan wait, then it would trigger action that would help free up memory orreplenish the pool (without deadlocking) and wait for availability in the pool.If it is in IRQ context, and hence not in a position to do this, allocationcould fail if the pool is empty. In general mempool always first tries toperform allocation without having to wait, even if it means digging into thepool as long it is not less that 50% full.

On a free, memory is released to the pool or directly freed depending onthe current availability in the pool. The mempool interface lets thesubsystem specify the routines to be used for normal alloc and free. In thecase of bio, these routines make use of the standard slab allocator.

The caller of bio_alloc is expected to taken certain steps to avoiddeadlocks, e.g. avoid trying to allocate more memory from the pool whilealready holding memory obtained from the pool.

[TBD: This is a potential issue, though a rare possibility in the bounce bio allocation that happens in the current code, since it ends up allocating a second bio from the same pool while holding the original bio ]

Memory allocated from the pool should be released back within a limitedamount of time (in the case of bio, that would be after the i/o is completed).This ensures that if part of the pool has been used up, some work (in thiscase i/o) must already be in progress and memory would be available when itis over. If allocating from multiple pools in the same code path, the orderor hierarchy of allocation needs to be consistent, just the way one dealswith multiple locks.

The bio_alloc routine also needs to allocate the bio_vec_list (bvec_alloc())for a non-clone bio. There are the 6 pools setup for different size biovecs,so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of thegiven size from these slabs.

The bio_get() routine may be used to hold an extra reference on a bio priorto i/o submission, if the bio fields are likely to be accessed after thei/o is issued (since the bio may otherwise get freed in case i/o completionhappens in the meantime).

Thebio_clone_fast() routine may be used to duplicate a bio, where the cloneshares the bio_vec_list with the original bio (i.e. both point to thesame bio_vec_list). This would typically be used for splitting i/o requestsin lvm or md.

3.2 Generic bio helper Routines¶

struct req_iterator iter;rq_for_each_segment(bio_vec, rq, iter)        /* bio_vec is now current segment */

3.3 I/O Submission¶

The routinesubmit_bio() is used to submit a single io. Higher level i/oroutines make use of this:

1. Buffered i/o:

The routine submit_bh() invokessubmit_bio() on a bio corresponding to thebh, allocating the bio if required.ll_rw_block() uses submit_bh() as before.

2. Kiobuf i/o (for raw/direct i/o):

The ll_rw_kio() routine breaks up the kiobuf into page sized chunks andmaps the array to one or more multi-page bios, issuingsubmit_bio() toperform the i/o on each of these.

The embedded bh array in the kiobuf structure has been removed and nopreallocation of bios is done for kiobufs. [The intent is to remove theblocks array as well, but it’s currently in there to kludge around direct i/o.]Thus kiobuf allocation has switched back to using kmalloc rather than vmalloc.

Todo/Observation:

A single kiobuf structure is assumed to correspond to a contiguous rangeof data, so brw_kiovec() invokes ll_rw_kio for each kiobuf in a kiovec.So right now it wouldn’t work for direct i/o on non-contiguous blocks.This is to be resolved. The eventual direction is to replace kiobufby kvec’s.

Badari Pulavarty has a patch to implement direct i/o correctly usingbio and kvec.

3. Page i/o:

Todo/Under discussion:

Andrew Morton’s multi-page bio patches attempt to issue multi-pagewriteouts (and reads) from the page cache, by directly building uplarge bios for submission completely bypassing the usage of bufferheads. This work is still in progress.

Christoph Hellwig had some code that uses bios for page-io (rather thanbh). This isn’t included in bio as yet. Christoph was also working on adesign for representing virtual/real extents as an entity and modifyingsome of the address space ops interfaces to utilize this abstraction ratherthan buffer_heads. (This is somewhat along the lines of the SGI XFS pagebufabstraction, but intended to be as lightweight as possible).

4. Direct access i/o:

Direct access requests that do not contain bios would be submitted differentlyas discussed earlier in section 1.3.

Aside:

Kvec i/o:

Ben LaHaise’s aio code uses a slightly different structure insteadof kiobufs, called a kvec_cb. This contains an array of <page, offset, len>tuples (very much like the networking code), together with a callback functionand data pointer. This is embedded into a brw_cb structure when passedto brw_kvec_async().

Now it should be possible to directly map these kvecs to a bio. Just as whilecloning, in this case rather than PRE_BUILT bio_vecs, we set the bi_io_vecarray pointer to point to the veclet array in kvecs.

TBD: In order for this to work, some changes are needed in the way multi-pagebios are handled today. The values of the tuples in such a vector passed infrom higher level code should not be modified by the block layer in the courseof its request processing, since that would make it hard for the higher layerto continue to use the vector descriptor (kvec) after i/o completes. Instead,all such transient state should either be maintained in the request structure,and passed on in some way to the endio completion routine.

4.1. I/O scheduler API¶

The functions an elevator may implement are: (* are mandatory)

4.2 Request flows seen by I/O schedulers¶

All requests seen by I/O schedulers strictly follow one of the following threeflows.

set_req_fn ->

1. add_req_fn -> (merged_fn ->)* -> dispatch_fn -> activate_req_fn ->(deactivate_req_fn -> activate_req_fn ->)* -> completed_req_fn
2. add_req_fn -> (merged_fn ->)* -> merge_req_fn
3. [none]

-> put_req_fn

4.3 I/O scheduler implementation¶

The generic i/o scheduler algorithm attempts to sort/merge/batch requests foroptimal disk scan and request servicing performance (based on genericprinciples and device capabilities), optimized for:

1. improved throughput
2. improved latency
3. better utilization of h/w & CPU time

Characteristics:

i. Binary treeAS and deadline i/o schedulers use red black binary trees for disk positionsorting and searching, and a fifo linked list for time-based searching. Thisgives good scalability and good availability of information. Requests arealmost always dispatched in disk sort order, so a cache is kept of the nextrequest in sort order to prevent binary tree lookups.

This arrangement is not a generic block layer characteristic however, soelevators may implement queues as they please.

ii. Merge hashAS and deadline use a hash table indexed by the last sector of a request. Thisenables merging code to quickly look up “back merge” candidates, even whenmultiple I/O streams are being performed at once on one disk.

“Front merges”, a new request being merged at the front of an existing request,are far less common than “back merges” due to the nature of most I/O patterns.Front merges are handled by the binary trees in AS and deadline schedulers.

3. Plugging the queue to batch requests in anticipation of opportunities formerge/sort optimizations

Plugging is an approach that the current i/o scheduling algorithm resorts to sothat it collects up enough requests in the queue to be able to takeadvantage of the sorting/merging logic in the elevator. If thequeue is empty when a request comes in, then it plugs the request queue(sort of like plugging the bath tub of a vessel to get fluid to build up)till it fills up with a few more requests, before starting to servicethe requests. This provides an opportunity to merge/sort the requests beforepassing them down to the device. There are various conditions when the queue isunplugged (to open up the flow again), either through a scheduled task orcould be on demand. For example wait_on_buffer sets the unplugging goingthrough sync_buffer() running blk_run_address_space(mapping). Or the callercan do it explicity through blk_unplug(bdev). So in the read case,the queue gets explicitly unplugged as part of waiting for completion on thatbuffer.

Aside:

This is kind of controversial territory, as it’s not clear if plugging isalways the right thing to do. Devices typically have their own queues,and allowing a big queue to build up in software, while letting the device beidle for a while may not always make sense. The trick is to handle the finebalance between when to plug and when to open up. Also now that we havemulti-page bios being queued in one shot, we may not need to wait to mergea big request from the broken up pieces coming by.

4.4 I/O contexts¶

I/O contexts provide a dynamically allocated per process data area. They maybe used in I/O schedulers, and in the block layer (could be used for IO statis,priorities for example). See*io_context in block/ll_rw_blk.c, and as-iosched.cfor an example of usage in an i/o scheduler.

5.1 Granular Locking: io_request_lock replaced by a per-queue lock¶

The global io_request_lock has been removed as of 2.5, to avoidthe scalability bottleneck it was causing, and has been replaced by moregranular locking. The request queue structure has a pointer to thelock to be used for that queue. As a result, locking can now beper-queue, with a provision for sharing a lock across queues ifnecessary (e.g the scsi layer sets the queue lock pointers to thecorresponding adapter lock, which results in a per host lockinggranularity). The locking semantics are the same, i.e. locking isstill imposed by the block layer, grabbing the lock beforerequest_fn execution which it means that lots of older driversshould still be SMP safe. Drivers are free to drop the queuelock themselves, if required. Drivers that explicitly used theio_request_lock for serialization need to be modified accordingly.Usually it’s as easy as adding a global lock:

static DEFINE_SPINLOCK(my_driver_lock);

and passing the address to that lock to blk_init_queue().

5.2 64 bit sector numbers (sector_t prepares for 64 bit support)¶

The sector number used in the bio structure has been changed to sector_t,which could be defined as 64 bit in preparation for 64 bit sector support.

6.1 Partition re-mapping handled by the generic block layer¶

In 2.5 some of the gendisk/partition related code has been reorganized.Now the generic block layer performs partition-remapping early and thusprovides drivers with a sector number relative to whole device, rather thanhaving to take partition number into account in order to arrive at the truesector number. The routine blk_partition_remap() is invoked bysubmit_bio_noacct even before invoking the queue specific ->submit_bio,so the i/o scheduler also gets to operate on whole disk sector numbers. Thisshould typically not require changes to block drivers, it just never getsto invoke its own partition sector offset calculations since all biossent are offset from the beginning of the device.

8.1. Earlier kiobuf patches (sct/axboe/chait/hch/mkp)¶

• orig kiobuf & raw i/o patches (now in 2.4 tree)
• direct kiobuf based i/o to devices (no intermediate bh’s)
• page i/o using kiobuf
• kiobuf splitting for lvm (mkp)
• elevator support for kiobuf request merging (axboe)

8.2. Zero-copy networking (Dave Miller)¶

8.3. SGI XFS - pagebuf patches - use of kiobufs¶

8.4. Multi-page pioent patch for bio (Christoph Hellwig)¶

8.5. Direct i/o implementation (Andrea Arcangeli) since 2.4.10-pre11¶

8.6. Async i/o implementation patch (Ben LaHaise)¶

8.7. EVMS layering design (IBM EVMS team)¶

8.8. Larger page cache size patch (Ben LaHaise) and Large page size (Daniel Phillips)¶

=> larger contiguous physical memory buffers

8.9. VM reservations patch (Ben LaHaise)¶

8.10. Write clustering patches ? (Marcelo/Quintela/Riel ?)¶

8.11. Block device in page cache patch (Andrea Archangeli) - now in 2.4.10+¶

8.12. Multiple block-size transfers for faster raw i/o (Shailabh Nagar, Badari)¶

8.13 Priority based i/o scheduler - prepatches (Arjan van de Ven)¶

8.14 IDE Taskfile i/o patch (Andre Hedrick)¶

8.15 Multi-page writeout and readahead patches (Andrew Morton)¶

8.16 Direct i/o patches for 2.5 using kvec and bio (Badari Pulavarthy)¶

9.1 The Splice I/O Model¶

Larry McVoy (and subsequent discussions on lkml, 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 theinitial thoughts that led to bio were brought up in this discussion thread)

9.3 Discussions on mempool on lkml - Dec 2001.¶