Loading Documentation/ABI/obsolete/proc-pid-oom_adj 0 → 100644 +22 −0 Original line number Original line Diff line number Diff line 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. Documentation/DocBook/uio-howto.tmpl +3 −3 Original line number Original line Diff line number Diff line Loading @@ -16,7 +16,7 @@ </orgname> </orgname> <address> <address> <email>hjk@linutronix.de</email> <email>hjk@hansjkoch.de</email> </address> </address> </affiliation> </affiliation> </author> </author> Loading Loading @@ -114,7 +114,7 @@ GPL version 2. <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> Loading Loading @@ -171,7 +171,7 @@ interested in translating it, please email me <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> Loading Documentation/arm/OMAP/DSS +4 −3 Original line number Original line Diff line number Diff line Loading @@ -255,9 +255,10 @@ framebuffer parameters. 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, Loading Documentation/block/switching-sched.txt +4 −4 Original line number Original line Diff line number Diff line Loading @@ -16,7 +16,7 @@ you can do so by typing: 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: Loading @@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names 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 Documentation/development-process/2.Process +23 −10 Original line number Original line Diff line number Diff line Loading @@ -154,7 +154,7 @@ The stages that a patch goes through are, generally: 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. Loading Loading @@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not 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 Loading @@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of 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 Loading @@ -275,7 +275,7 @@ directory at: 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 Loading Loading @@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target. 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 Loading Loading
Documentation/ABI/obsolete/proc-pid-oom_adj 0 → 100644 +22 −0 Original line number Original line Diff line number Diff line 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.
Documentation/DocBook/uio-howto.tmpl +3 −3 Original line number Original line Diff line number Diff line Loading @@ -16,7 +16,7 @@ </orgname> </orgname> <address> <address> <email>hjk@linutronix.de</email> <email>hjk@hansjkoch.de</email> </address> </address> </affiliation> </affiliation> </author> </author> Loading Loading @@ -114,7 +114,7 @@ GPL version 2. <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> Loading Loading @@ -171,7 +171,7 @@ interested in translating it, please email me <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> Loading
Documentation/arm/OMAP/DSS +4 −3 Original line number Original line Diff line number Diff line Loading @@ -255,9 +255,10 @@ framebuffer parameters. 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, Loading
Documentation/block/switching-sched.txt +4 −4 Original line number Original line Diff line number Diff line Loading @@ -16,7 +16,7 @@ you can do so by typing: 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: Loading @@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names 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
Documentation/development-process/2.Process +23 −10 Original line number Original line Diff line number Diff line Loading @@ -154,7 +154,7 @@ The stages that a patch goes through are, generally: 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. Loading Loading @@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not 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 Loading @@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of 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 Loading @@ -275,7 +275,7 @@ directory at: 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 Loading Loading @@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target. 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 Loading
