Merge branch 'master'

#

# NOTE! Don't add files that are generated in specific

# subdirectories here. Add them in the ".gitignore" file

# in that subdirectory instead.

#

# Normal rules

#

.*

*.o

*.a

*.s

*.ko

*.mod.c

#

# Top-level generic files

#

vmlinux*

System.map

Module.symvers

#

# Generated include files

#

include/asm

include/config

include/linux/autoconf.h

include/linux/compile.h

include/linux/version.h

udev is a userspace application for populating /dev dynamically with

only entries for devices actually present. udev replaces devfs.

FUSE

----

Needs libfuse 2.4.0 or later.  Absolute minimum is 2.3.0 but mount

options 'direct_io' and 'kernel_cache' won't work.

Networking

==========

----

o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>

FUSE

----

o <http://sourceforge.net/projects/fuse>

Networking

**********

point out some special detail about the sign-off. 

12) The canonical patch format

12) More references for submitting patches

The canonical patch subject line is:

    Subject: [PATCH 001/123] subsystem: summary phrase

The canonical patch message body contains the following:

  - A "from" line specifying the patch author.

  - An empty line.

  - The body of the explanation, which will be copied to the

    permanent changelog to describe this patch.

  - The "Signed-off-by:" lines, described above, which will

    also go in the changelog.

  - A marker line containing simply "---".

  - Any additional comments not suitable for the changelog.

  - The actual patch (diff output).

The Subject line format makes it very easy to sort the emails

alphabetically by subject line - pretty much any email reader will

support that - since because the sequence number is zero-padded,

the numerical and alphabetic sort is the same.

The "subsystem" in the email's Subject should identify which

area or subsystem of the kernel is being patched.

The "summary phrase" in the email's Subject should concisely

describe the patch which that email contains.  The "summary

phrase" should not be a filename.  Do not use the same "summary

phrase" for every patch in a whole patch series.

Bear in mind that the "summary phrase" of your email becomes

a globally-unique identifier for that patch.  It propagates

all the way into the git changelog.  The "summary phrase" may

later be used in developer discussions which refer to the patch.

People will want to google for the "summary phrase" to read

discussion regarding that patch.

A couple of example Subjects:

    Subject: [patch 2/5] ext2: improve scalability of bitmap searching

    Subject: [PATCHv2 001/207] x86: fix eflags tracking

The "from" line must be the very first line in the message body,

and has the form:

        From: Original Author <author@example.com>

The "from" line specifies who will be credited as the author of the

patch in the permanent changelog.  If the "from" line is missing,

then the "From:" line from the email header will be used to determine

the patch author in the changelog.

The explanation body will be committed to the permanent source

changelog, so should make sense to a competent reader who has long

since forgotten the immediate details of the discussion that might

have led to this patch.

The "---" marker line serves the essential purpose of marking for patch

handling tools where the changelog message ends.

One good use for the additional comments after the "---" marker is for

a diffstat, to show what files have changed, and the number of inserted

and deleted lines per file.  A diffstat is especially useful on bigger

patches.  Other comments relevant only to the moment or the maintainer,

not suitable for the permanent changelog, should also go here.

See more details on the proper patch format in the following

references.

13) More references for submitting patches

Andrew Morton, "The perfect patch" (tpp).

  <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>

Jeff Garzik, "Linux kernel patch submission format."

  <http://linux.yyz.us/patch-format.html>

Greg KH, "How to piss off a kernel subsystem maintainer"

  <http://www.kroah.com/log/2005/03/31/>

Kernel Documentation/CodingStyle

  <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>

Linus Torvald's mail on the canonical patch format:

  <http://lkml.org/lkml/2005/4/7/183>

-----------------------------------

4. The I/O scheduler

I/O schedulers are now per queue. They should be runtime switchable and modular

but aren't yet. Jens has most bits to do this, but the sysfs implementation is

missing.

I/O scheduler, a.k.a. elevator, is implemented in two layers.  Generic dispatch

queue and specific I/O schedulers.  Unless stated otherwise, elevator is used

to refer to both parts and I/O scheduler to specific I/O schedulers.

Block layer implements generic dispatch queue in ll_rw_blk.c and elevator.c.

The generic dispatch queue is responsible for properly ordering barrier

requests, requeueing, handling non-fs requests and all other subtleties.

Specific I/O schedulers are responsible for ordering normal filesystem

requests.  They can also choose to delay certain requests to improve

throughput or whatever purpose.  As the plural form indicates, there are

multiple I/O schedulers.  They can be built as modules but at least one should

be built inside the kernel.  Each queue can choose different one and can also

change to another one dynamically.

A block layer call to the i/o scheduler follows the convention elv_xxx(). This

calls elevator_xxx_fn in the elevator switch (drivers/block/elevator.c). Oh,

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

elevator_merge_fn		called to query requests for merge with a bio

elevator_merge_req_fn		" " "  with another request

elevator_merge_req_fn		called when two requests get merged. the one

				which gets merged into the other one will be

				never seen by I/O scheduler again. IOW, after

				being merged, the request is gone.

elevator_merged_fn		called when a request in the scheduler has been

				involved in a merge. It is used in the deadline

				scheduler for example, to reposition the request

				if its sorting order has changed.

*elevator_next_req_fn		returns the next scheduled request, or NULL

				if there are none (or none are ready).

elevator_dispatch_fn		fills the dispatch queue with ready requests.

				I/O schedulers are free to postpone requests by

				not filling the dispatch queue unless @force

				is non-zero.  Once dispatched, I/O schedulers

				are not allowed to manipulate the requests -

				they belong to generic dispatch queue.

*elevator_add_req_fn		called to add a new request into the scheduler

elevator_add_req_fn		called to add a new request into the scheduler

elevator_queue_empty_fn		returns true if the merge queue is empty.

				Drivers shouldn't use this, but rather check

				if elv_next_request is NULL (without losing the

				request if one exists!)

elevator_remove_req_fn		This is called when a driver claims ownership of

				the target request - it now belongs to the

				driver. It must not be modified or merged.

				Drivers must not lose the request! A subsequent

				call of elevator_next_req_fn must  return the

				_next_ request.

elevator_requeue_req_fn		called to add a request to the scheduler. This

				is used when the request has alrnadebeen

				returned by elv_next_request, but hasn't

				completed. If this is not implemented then

				elevator_add_req_fn is called instead.

elevator_former_req_fn

elevator_latter_req_fn		These return the request before or after the

				one specified in disk sort order. Used by the

				block layer to find merge possibilities.

elevator_completed_req_fn	called when a request is completed. This might

				come about due to being merged with another or

				when the device completes the request.

elevator_completed_req_fn	called when a request is completed.

elevator_may_queue_fn		returns true if the scheduler wants to allow the

				current context to queue a new request even if

elevator_set_req_fn

elevator_put_req_fn		Must be used to allocate and free any elevator

				specific storate for a request.

				specific storage for a request.

elevator_activate_req_fn	Called when device driver first sees a request.

				I/O schedulers can use this callback to

				determine when actual execution of a request

				starts.

elevator_deactivate_req_fn	Called when device driver decides to delay

				a request by requeueing it.

elevator_init_fn

elevator_exit_fn		Allocate and free any elevator specific storage

				for a queue.

4.2 I/O scheduler implementation

4.2 Request flows seen by I/O schedulers

All requests seens by I/O schedulers strictly follow one of the following three

flows.

 set_req_fn ->

 i.   add_req_fn -> (merged_fn ->)* -> dispatch_fn -> activate_req_fn ->

      (deactivate_req_fn -> activate_req_fn ->)* -> completed_req_fn

 ii.  add_req_fn -> (merged_fn ->)* -> merge_req_fn

 iii. [none]

 -> put_req_fn

4.3 I/O scheduler implementation

The generic i/o scheduler algorithm attempts to sort/merge/batch requests for

optimal disk scan and request servicing performance (based on generic

principles and device capabilities), optimized for:

This arrangement is not a generic block layer characteristic however, so

elevators may implement queues as they please.

ii. Last merge hint

The last merge hint is part of the generic queue layer. I/O schedulers must do

some management on it. For the most part, the most important thing is to make

sure q->last_merge is cleared (set to NULL) when the request on it is no longer

a candidate for merging (for example if it has been sent to the driver).

The last merge performed is cached as a hint for the subsequent request. If

sequential data is being submitted, the hint is used to perform merges without

any scanning. This is not sufficient when there are multiple processes doing

I/O though, so a "merge hash" is used by some schedulers.

iii. Merge hash

ii. Merge hash

AS and deadline use a hash table indexed by the last sector of a request. This

enables merging code to quickly look up "back merge" candidates, even when

multiple I/O streams are being performed at once on one disk.

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.

iv. Handling barrier cases

A request with flags REQ_HARDBARRIER or REQ_SOFTBARRIER must not be ordered

around. That is, they must be processed after all older requests, and before

any newer ones. This includes merges!

In AS and deadline schedulers, barriers have the effect of flushing the reorder

queue. The performance cost of this will vary from nothing to a lot depending

on i/o patterns and device characteristics. Obviously they won't improve

performance, so their use should be kept to a minimum.

v. Handling insertion position directives

A request may be inserted with a position directive. The directives are one of

ELEVATOR_INSERT_BACK, ELEVATOR_INSERT_FRONT, ELEVATOR_INSERT_SORT.

ELEVATOR_INSERT_SORT is a general directive for non-barrier requests.

ELEVATOR_INSERT_BACK is used to insert a barrier to the back of the queue.

ELEVATOR_INSERT_FRONT is used to insert a barrier to the front of the queue, and

overrides the ordering requested by any previous barriers. In practice this is

harmless and required, because it is used for SCSI requeueing. This does not

require flushing the reorder queue, so does not impose a performance penalty.

vi. Plugging the queue to batch requests in anticipation of opportunities for

iii. Plugging the queue to batch requests in anticipation of opportunities for

     merge/sort optimizations

This is just the same as in 2.4 so far, though per-device unplugging

  blk_kick_queue() to unplug a specific queue (right away ?)

  or optionally, all queues, is in the plan.

4.3 I/O contexts

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