Merge branch 'master' into for-linus

What:	/proc/<pid>/oom_adj

When:	August 2012

Why:	/proc/<pid>/oom_adj allows userspace to influence the oom killer's

	badness heuristic used to determine which task to kill when the kernel

	is out of memory.

	The badness heuristic has since been rewritten since the introduction of

	this tunable such that its meaning is deprecated.  The value was

	implemented as a bitshift on a score generated by the badness()

	function that did not have any precise units of measure.  With the

	rewrite, the score is given as a proportion of available memory to the

	task allocating pages, so using a bitshift which grows the score

	exponentially is, thus, impossible to tune with fine granularity.

	A much more powerful interface, /proc/<pid>/oom_score_adj, was

	introduced with the oom killer rewrite that allows users to increase or

	decrease the badness() score linearly.  This interface will replace

	/proc/<pid>/oom_adj.

	A warning will be emitted to the kernel log if an application uses this

	deprecated interface.  After it is printed once, future warnings will be

	suppressed until the kernel is rebooted.

	</orgname>

	</orgname>

	<address>

	<address>

	   <email>hjk@linutronix.de</email>

	   <email>hjk@hansjkoch.de</email>

	</address>

	</address>

    </affiliation>

    </affiliation>

</author>

</author>

<para>If you know of any translations for this document, or you are

<para>If you know of any translations for this document, or you are

interested in translating it, please email me

interested in translating it, please email me

<email>hjk@linutronix.de</email>.

<email>hjk@hansjkoch.de</email>.

</para>

</para>

</sect1>

</sect1>

<title>Feedback</title>

<title>Feedback</title>

	<para>Find something wrong with this document? (Or perhaps something

	<para>Find something wrong with this document? (Or perhaps something

	right?) I would love to hear from you. Please email me at

	right?) I would love to hear from you. Please email me at

	<email>hjk@linutronix.de</email>.</para>

	<email>hjk@hansjkoch.de</email>.</para>

</sect1>

</sect1>

</chapter>

</chapter>

Kernel boot arguments

Kernel boot arguments

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

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

vram=<size>

vram=<size>[,<physaddr>]

	- Amount of total VRAM to preallocate. For example, "10M". omapfb

	- Amount of total VRAM to preallocate and optionally a physical start

	  allocates memory for framebuffers from VRAM.

	  memory address. For example, "10M". omapfb allocates memory for

	  framebuffers from VRAM.

omapfb.mode=<display>:<mode>[,...]

omapfb.mode=<display>:<mode>[,...]

	- Default video mode for specified displays. For example,

	- Default video mode for specified displays. For example,

As of the Linux 2.6.10 kernel, it is now possible to change the

As of the Linux 2.6.10 kernel, it is now possible to change the

IO scheduler for a given block device on the fly (thus making it possible,

IO scheduler for a given block device on the fly (thus making it possible,

for instance, to set the CFQ scheduler for the system default, but

for instance, to set the CFQ scheduler for the system default, but

set a specific device to use the anticipatory or noop schedulers - which

set a specific device to use the deadline or noop schedulers - which

can improve that device's throughput).

can improve that device's throughput).

To set a specific scheduler, simply do this:

To set a specific scheduler, simply do this:

will be displayed, with the currently selected scheduler in brackets:

will be displayed, with the currently selected scheduler in brackets:

# cat /sys/block/hda/queue/scheduler

# cat /sys/block/hda/queue/scheduler

noop anticipatory deadline [cfq]

noop deadline [cfq]

# echo anticipatory > /sys/block/hda/queue/scheduler

# echo deadline > /sys/block/hda/queue/scheduler

# cat /sys/block/hda/queue/scheduler

# cat /sys/block/hda/queue/scheduler

noop [anticipatory] deadline cfq

noop [deadline] cfq

   inclusion, it should be accepted by a relevant subsystem maintainer -

   inclusion, it should be accepted by a relevant subsystem maintainer -

   though this acceptance is not a guarantee that the patch will make it

   though this acceptance is not a guarantee that the patch will make it

   all the way to the mainline.  The patch will show up in the maintainer's

   all the way to the mainline.  The patch will show up in the maintainer's

   subsystem tree and into the staging trees (described below).  When the

   subsystem tree and into the -next trees (described below).  When the

   process works, this step leads to more extensive review of the patch and

   process works, this step leads to more extensive review of the patch and

   the discovery of any problems resulting from the integration of this

   the discovery of any problems resulting from the integration of this

   patch with work being done by others.

   patch with work being done by others.

normally the right way to go.

normally the right way to go.

2.4: STAGING TREES

2.4: NEXT TREES

The chain of subsystem trees guides the flow of patches into the kernel,

The chain of subsystem trees guides the flow of patches into the kernel,

but it also raises an interesting question: what if somebody wants to look

but it also raises an interesting question: what if somebody wants to look

the interesting subsystem trees, but that would be a big and error-prone

the interesting subsystem trees, but that would be a big and error-prone

job.

job.

The answer comes in the form of staging trees, where subsystem trees are

The answer comes in the form of -next trees, where subsystem trees are

collected for testing and review.  The older of these trees, maintained by

collected for testing and review.  The older of these trees, maintained by

Andrew Morton, is called "-mm" (for memory management, which is how it got

Andrew Morton, is called "-mm" (for memory management, which is how it got

started).  The -mm tree integrates patches from a long list of subsystem

started).  The -mm tree integrates patches from a long list of subsystem

Use of the MMOTM tree is likely to be a frustrating experience, though;

Use of the MMOTM tree is likely to be a frustrating experience, though;

there is a definite chance that it will not even compile.

there is a definite chance that it will not even compile.

The other staging tree, started more recently, is linux-next, maintained by

The other -next tree, started more recently, is linux-next, maintained by

Stephen Rothwell.  The linux-next tree is, by design, a snapshot of what

Stephen Rothwell.  The linux-next tree is, by design, a snapshot of what

the mainline is expected to look like after the next merge window closes.

the mainline is expected to look like after the next merge window closes.

Linux-next trees are announced on the linux-kernel and linux-next mailing

Linux-next trees are announced on the linux-kernel and linux-next mailing

See http://lwn.net/Articles/289013/ for more information on this topic, and

See http://lwn.net/Articles/289013/ for more information on this topic, and

stay tuned; much is still in flux where linux-next is involved.

stay tuned; much is still in flux where linux-next is involved.

Besides the mmotm and linux-next trees, the kernel source tree now contains

2.4.1: STAGING TREES

the drivers/staging/ directory and many sub-directories for drivers or

filesystems that are on their way to being added to the kernel tree

The kernel source tree now contains the drivers/staging/ directory, where

proper, but they remain in drivers/staging/ while they still need more

many sub-directories for drivers or filesystems that are on their way to

work.

being added to the kernel tree live.  They remain in drivers/staging while

they still need more work; once complete, they can be moved into the

kernel proper.  This is a way to keep track of drivers that aren't

up to Linux kernel coding or quality standards, but people may want to use

them and track development.

Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree.

Drivers that still need work are sent to him, with each driver having

its own subdirectory in drivers/staging/.  Along with the driver source

files, a TODO file should be present in the directory as well.  The TODO

file lists the pending work that the driver needs for acceptance into

the kernel proper, as well as a list of people that should be Cc'd for any

patches to the driver.  Staging drivers that don't currently build should

have their config entries depend upon CONFIG_BROKEN.  Once they can

be successfully built without outside patches, CONFIG_BROKEN can be removed.

2.5: TOOLS

2.5: TOOLS