Loading Documentation/ABI/obsolete/proc-pid-oom_adj 0 → 100644 +22 −0 Original line number 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/block/switching-sched.txt +4 −4 Original line number 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 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 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). 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: # cat /sys/block/hda/queue/scheduler noop anticipatory deadline [cfq] # echo anticipatory > /sys/block/hda/queue/scheduler noop deadline [cfq] # echo deadline > /sys/block/hda/queue/scheduler # cat /sys/block/hda/queue/scheduler noop [anticipatory] deadline cfq noop [deadline] cfq Documentation/filesystems/xfs-delayed-logging-design.txt +0 −11 Original line number Diff line number Diff line Loading @@ -794,17 +794,6 @@ designed. Roadmap: 2.6.37 Remove experimental tag from mount option => should be roughly 6 months after initial merge => enough time to: => gain confidence and fix problems reported by early adopters (a.k.a. guinea pigs) => address worst performance regressions and undesired behaviours => start tuning/optimising code for parallelism => start tuning/optimising algorithms consuming excessive CPU time 2.6.39 Switch default mount option to use delayed logging => should be roughly 12 months after initial merge => enough time to shake out remaining problems before next round of Loading Documentation/kernel-parameters.txt +1 −1 Original line number Diff line number Diff line Loading @@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file arch/x86/kernel/cpu/cpufreq/elanfreq.c. elevator= [IOSCHED] Format: {"anticipatory" | "cfq" | "deadline" | "noop"} Format: {"cfq" | "deadline" | "noop"} See Documentation/block/as-iosched.txt and Documentation/block/deadline-iosched.txt for details. Loading Documentation/leds-class.txt +12 −9 Original line number Diff line number Diff line Loading @@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs Some LEDs can be programmed to blink without any CPU interaction. To support this feature, a LED driver can optionally implement the blink_set() function (see <linux/leds.h>). If implemented, triggers can attempt to use it before falling back to software timers. The blink_set() function should return 0 if the blink setting is supported, or -EINVAL otherwise, which means that LED blinking will be handled by software. The blink_set() function should choose a user friendly blinking value if it is called with *delay_on==0 && *delay_off==0 parameters. In this case the driver should give back the chosen value through delay_on and delay_off parameters to the leds subsystem. blink_set() function (see <linux/leds.h>). To set an LED to blinking, however, it is better to use use the API function led_blink_set(), as it will check and implement software fallback if necessary. To turn off blinking again, use the API function led_brightness_set() as that will not just set the LED brightness but also stop any software timers that may have been required for blinking. The blink_set() function should choose a user friendly blinking value if it is called with *delay_on==0 && *delay_off==0 parameters. In this case the driver should give back the chosen value through delay_on and delay_off parameters to the leds subsystem. Setting the brightness to zero with brightness_set() callback function should completely turn off the LED and cancel the previously programmed Loading Loading
Documentation/ABI/obsolete/proc-pid-oom_adj 0 → 100644 +22 −0 Original line number 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/block/switching-sched.txt +4 −4 Original line number 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 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 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). 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: # cat /sys/block/hda/queue/scheduler noop anticipatory deadline [cfq] # echo anticipatory > /sys/block/hda/queue/scheduler noop deadline [cfq] # echo deadline > /sys/block/hda/queue/scheduler # cat /sys/block/hda/queue/scheduler noop [anticipatory] deadline cfq noop [deadline] cfq
Documentation/filesystems/xfs-delayed-logging-design.txt +0 −11 Original line number Diff line number Diff line Loading @@ -794,17 +794,6 @@ designed. Roadmap: 2.6.37 Remove experimental tag from mount option => should be roughly 6 months after initial merge => enough time to: => gain confidence and fix problems reported by early adopters (a.k.a. guinea pigs) => address worst performance regressions and undesired behaviours => start tuning/optimising code for parallelism => start tuning/optimising algorithms consuming excessive CPU time 2.6.39 Switch default mount option to use delayed logging => should be roughly 12 months after initial merge => enough time to shake out remaining problems before next round of Loading
Documentation/kernel-parameters.txt +1 −1 Original line number Diff line number Diff line Loading @@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file arch/x86/kernel/cpu/cpufreq/elanfreq.c. elevator= [IOSCHED] Format: {"anticipatory" | "cfq" | "deadline" | "noop"} Format: {"cfq" | "deadline" | "noop"} See Documentation/block/as-iosched.txt and Documentation/block/deadline-iosched.txt for details. Loading
Documentation/leds-class.txt +12 −9 Original line number Diff line number Diff line Loading @@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs Some LEDs can be programmed to blink without any CPU interaction. To support this feature, a LED driver can optionally implement the blink_set() function (see <linux/leds.h>). If implemented, triggers can attempt to use it before falling back to software timers. The blink_set() function should return 0 if the blink setting is supported, or -EINVAL otherwise, which means that LED blinking will be handled by software. The blink_set() function should choose a user friendly blinking value if it is called with *delay_on==0 && *delay_off==0 parameters. In this case the driver should give back the chosen value through delay_on and delay_off parameters to the leds subsystem. blink_set() function (see <linux/leds.h>). To set an LED to blinking, however, it is better to use use the API function led_blink_set(), as it will check and implement software fallback if necessary. To turn off blinking again, use the API function led_brightness_set() as that will not just set the LED brightness but also stop any software timers that may have been required for blinking. The blink_set() function should choose a user friendly blinking value if it is called with *delay_on==0 && *delay_off==0 parameters. In this case the driver should give back the chosen value through delay_on and delay_off parameters to the leds subsystem. Setting the brightness to zero with brightness_set() callback function should completely turn off the LED and cancel the previously programmed Loading
