You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge commit '8700c95adb03' into timers/nohz
The full dynticks tree needs the latest RCU and sched upstream updates in order to fix some dependencies. Merge a common upstream merge point that has these updates. Conflicts: include/linux/perf_event.h kernel/rcutree.h kernel/rcutree_plugin.h Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
This commit is contained in:
Frederic Weisbecker
@@ -761,6 +761,10 @@ S: Northampton
|
||||
S: NN1 3QT
|
||||
S: United Kingdom
|
||||
|
||||
N: Massimo Dal Zotto
|
||||
E: dz@debian.org
|
||||
D: i8k Dell laptop SMM driver
|
||||
|
||||
N: Uwe Dannowski
|
||||
E: Uwe.Dannowski@ira.uka.de
|
||||
W: http://i30www.ira.uka.de/~dannowsk/
|
||||
@@ -953,11 +957,11 @@ S: Blacksburg, Virginia 24061
|
||||
S: USA
|
||||
|
||||
N: Randy Dunlap
|
||||
E: rdunlap@xenotime.net
|
||||
W: http://www.xenotime.net/linux/linux.html
|
||||
W: http://www.linux-usb.org
|
||||
E: rdunlap@infradead.org
|
||||
W: http://www.infradead.org/~rdunlap/
|
||||
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
||||
D: x86 SMP, ACPI, bootflag hacking
|
||||
D: documentation, builds
|
||||
S: (ask for current address)
|
||||
S: USA
|
||||
|
||||
@@ -1510,6 +1514,14 @@ D: Natsemi ethernet
|
||||
D: Cobalt Networks (x86) support
|
||||
D: This-and-That
|
||||
|
||||
N: Mark M. Hoffman
|
||||
E: mhoffman@lightlink.com
|
||||
D: asb100, lm93 and smsc47b397 hardware monitoring drivers
|
||||
D: hwmon subsystem core
|
||||
D: hwmon subsystem maintainer
|
||||
D: i2c-sis96x and i2c-stub SMBus drivers
|
||||
S: USA
|
||||
|
||||
N: Dirk Hohndel
|
||||
E: hohndel@suse.de
|
||||
D: The XFree86[tm] Project
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
What: /sys/bus/mei/devices/.../modalias
|
||||
Date: March 2013
|
||||
KernelVersion: 3.10
|
||||
Contact: Samuel Ortiz <sameo@linux.intel.com>
|
||||
linux-mei@linux.intel.com
|
||||
Description: Stores the same MODALIAS value emitted by uevent
|
||||
Format: mei:<mei device name>
|
||||
@@ -32,7 +32,7 @@ Date: January 2008
|
||||
KernelVersion: 2.6.25
|
||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||
Description:
|
||||
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
|
||||
If CONFIG_PM_RUNTIME is enabled then this file
|
||||
is present. When read, it returns the total time (in msec)
|
||||
that the USB device has been connected to the machine. This
|
||||
file is read-only.
|
||||
@@ -45,7 +45,7 @@ Date: January 2008
|
||||
KernelVersion: 2.6.25
|
||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||
Description:
|
||||
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
|
||||
If CONFIG_PM_RUNTIME is enabled then this file
|
||||
is present. When read, it returns the total time (in msec)
|
||||
that the USB device has been active, i.e. not in a suspended
|
||||
state. This file is read-only.
|
||||
@@ -187,7 +187,7 @@ What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
|
||||
Date: September 2011
|
||||
Contact: Andiry Xu <andiry.xu@amd.com>
|
||||
Description:
|
||||
If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
|
||||
If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
|
||||
is plugged in to a xHCI host which support link PM, it will
|
||||
perform a LPM test; if the test is passed and host supports
|
||||
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
|
||||
|
||||
@@ -173,3 +173,15 @@ Description: Processor frequency boosting control
|
||||
Boosting allows the CPU and the firmware to run at a frequency
|
||||
beyound it's nominal limit.
|
||||
More details can be found in Documentation/cpu-freq/boost.txt
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/crash_notes
|
||||
/sys/devices/system/cpu/cpu#/crash_notes_size
|
||||
Date: April 2013
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: address and size of the percpu note.
|
||||
|
||||
crash_notes: the physical address of the memory that holds the
|
||||
note of cpu#.
|
||||
|
||||
crash_notes_size: size of the note of cpu#.
|
||||
|
||||
@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Edrivers/tty/serial/serial_core.c
|
||||
!Edrivers/tty/serial/8250/8250.c
|
||||
!Edrivers/tty/serial/8250/8250_core.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="fbdev">
|
||||
|
||||
@@ -217,9 +217,14 @@ over a rather long period of time, but improvements are always welcome!
|
||||
whether the increased speed is worth it.
|
||||
|
||||
8. Although synchronize_rcu() is slower than is call_rcu(), it
|
||||
usually results in simpler code. So, unless update performance
|
||||
is critically important or the updaters cannot block,
|
||||
synchronize_rcu() should be used in preference to call_rcu().
|
||||
usually results in simpler code. So, unless update performance is
|
||||
critically important, the updaters cannot block, or the latency of
|
||||
synchronize_rcu() is visible from userspace, synchronize_rcu()
|
||||
should be used in preference to call_rcu(). Furthermore,
|
||||
kfree_rcu() usually results in even simpler code than does
|
||||
synchronize_rcu() without synchronize_rcu()'s multi-millisecond
|
||||
latency. So please take advantage of kfree_rcu()'s "fire and
|
||||
forget" memory-freeing capabilities where it applies.
|
||||
|
||||
An especially important property of the synchronize_rcu()
|
||||
primitive is that it automatically self-limits: if grace periods
|
||||
@@ -268,7 +273,8 @@ over a rather long period of time, but improvements are always welcome!
|
||||
e. Periodically invoke synchronize_rcu(), permitting a limited
|
||||
number of updates per grace period.
|
||||
|
||||
The same cautions apply to call_rcu_bh() and call_rcu_sched().
|
||||
The same cautions apply to call_rcu_bh(), call_rcu_sched(),
|
||||
call_srcu(), and kfree_rcu().
|
||||
|
||||
9. All RCU list-traversal primitives, which include
|
||||
rcu_dereference(), list_for_each_entry_rcu(), and
|
||||
@@ -296,9 +302,9 @@ over a rather long period of time, but improvements are always welcome!
|
||||
all currently executing rcu_read_lock()-protected RCU read-side
|
||||
critical sections complete. It does -not- necessarily guarantee
|
||||
that all currently running interrupts, NMIs, preempt_disable()
|
||||
code, or idle loops will complete. Therefore, if you do not have
|
||||
rcu_read_lock()-protected read-side critical sections, do -not-
|
||||
use synchronize_rcu().
|
||||
code, or idle loops will complete. Therefore, if your
|
||||
read-side critical sections are protected by something other
|
||||
than rcu_read_lock(), do -not- use synchronize_rcu().
|
||||
|
||||
Similarly, disabling preemption is not an acceptable substitute
|
||||
for rcu_read_lock(). Code that attempts to use preemption
|
||||
@@ -401,9 +407,9 @@ over a rather long period of time, but improvements are always welcome!
|
||||
read-side critical sections. It is the responsibility of the
|
||||
RCU update-side primitives to deal with this.
|
||||
|
||||
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
|
||||
the __rcu sparse checks to validate your RCU code. These
|
||||
can help find problems as follows:
|
||||
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
|
||||
__rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
|
||||
validate your RCU code. These can help find problems as follows:
|
||||
|
||||
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
|
||||
structures are carried out under the proper RCU
|
||||
|
||||
@@ -64,6 +64,11 @@ checking of rcu_dereference() primitives:
|
||||
but retain the compiler constraints that prevent duplicating
|
||||
or coalescsing. This is useful when when testing the
|
||||
value of the pointer itself, for example, against NULL.
|
||||
rcu_access_index(idx):
|
||||
Return the value of the index and omit all barriers, but
|
||||
retain the compiler constraints that prevent duplicating
|
||||
or coalescsing. This is useful when when testing the
|
||||
value of the index itself, for example, against -1.
|
||||
|
||||
The rcu_dereference_check() check expression can be any boolean
|
||||
expression, but would normally include a lockdep expression. However,
|
||||
|
||||
@@ -79,7 +79,20 @@ complete. Pseudo-code using rcu_barrier() is as follows:
|
||||
2. Execute rcu_barrier().
|
||||
3. Allow the module to be unloaded.
|
||||
|
||||
The rcutorture module makes use of rcu_barrier in its exit function
|
||||
There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier()
|
||||
functions for the other flavors of RCU, and you of course must match
|
||||
the flavor of rcu_barrier() with that of call_rcu(). If your module
|
||||
uses multiple flavors of call_rcu(), then it must also use multiple
|
||||
flavors of rcu_barrier() when unloading that module. For example, if
|
||||
it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on
|
||||
srcu_struct_2(), then the following three lines of code will be required
|
||||
when unloading:
|
||||
|
||||
1 rcu_barrier_bh();
|
||||
2 srcu_barrier(&srcu_struct_1);
|
||||
3 srcu_barrier(&srcu_struct_2);
|
||||
|
||||
The rcutorture module makes use of rcu_barrier() in its exit function
|
||||
as follows:
|
||||
|
||||
1 static void
|
||||
|
||||
@@ -92,14 +92,14 @@ If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
||||
more information is printed with the stall-warning message, for example:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
|
||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
|
||||
(t=65000 jiffies)
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
||||
printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
|
||||
(t=65000 jiffies)
|
||||
|
||||
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
||||
@@ -116,13 +116,28 @@ number between the two "/"s is the value of the nesting, which will
|
||||
be a small positive number if in the idle loop and a very large positive
|
||||
number (as shown above) otherwise.
|
||||
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
|
||||
not in the process of trying to force itself into dyntick-idle state, the
|
||||
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
|
||||
mode (it would be "H" otherwise), and the "timer not pending" indicates
|
||||
that the CPU has not recently forced RCU into dyntick-idle mode (it
|
||||
would otherwise indicate the number of microseconds remaining in this
|
||||
forced state).
|
||||
The "softirq=" portion of the message tracks the number of RCU softirq
|
||||
handlers that the stalled CPU has executed. The number before the "/"
|
||||
is the number that had executed since boot at the time that this CPU
|
||||
last noted the beginning of a grace period, which might be the current
|
||||
(stalled) grace period, or it might be some earlier grace period (for
|
||||
example, if the CPU might have been in dyntick-idle mode for an extended
|
||||
time period. The number after the "/" is the number that have executed
|
||||
since boot until the current time. If this latter number stays constant
|
||||
across repeated stall-warning messages, it is possible that RCU's softirq
|
||||
handlers are no longer able to execute on this CPU. This can happen if
|
||||
the stalled CPU is spinning with interrupts are disabled, or, in -rt
|
||||
kernels, if a high-priority process is starving RCU's softirq handler.
|
||||
|
||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the
|
||||
low-order 16 bits (in hex) of the jiffies counter when this CPU last
|
||||
invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked
|
||||
rcu_accelerate_cbs() from rcu_prepare_for_idle(). The "nonlazy_posted:"
|
||||
prints the number of non-lazy callbacks posted since the last call to
|
||||
rcu_needs_cpu(). Finally, an "L" indicates that there are currently
|
||||
no non-lazy callbacks ("." is printed otherwise, as shown above) and
|
||||
"D" indicates that dyntick-idle processing is enabled ("." is printed
|
||||
otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
|
||||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
|
||||
@@ -265,9 +265,9 @@ rcu_dereference()
|
||||
rcu_read_lock();
|
||||
p = rcu_dereference(head.next);
|
||||
rcu_read_unlock();
|
||||
x = p->address;
|
||||
x = p->address; /* BUG!!! */
|
||||
rcu_read_lock();
|
||||
y = p->data;
|
||||
y = p->data; /* BUG!!! */
|
||||
rcu_read_unlock();
|
||||
|
||||
Holding a reference from one RCU read-side critical section
|
||||
|
||||
@@ -60,8 +60,7 @@ own source tree. For example:
|
||||
"dontdiff" is a list of files which are generated by the kernel during
|
||||
the build process, and should be ignored in any diff(1)-generated
|
||||
patch. The "dontdiff" file is included in the kernel tree in
|
||||
2.6.12 and later. For earlier kernel versions, you can get it
|
||||
from <http://www.xenotime.net/linux/doc/dontdiff>.
|
||||
2.6.12 and later.
|
||||
|
||||
Make sure your patch does not include any extra files which do not
|
||||
belong in a patch submission. Make sure to review your patch -after-
|
||||
@@ -421,7 +420,7 @@ person it names. This tag documents that potentially interested parties
|
||||
have been included in the discussion
|
||||
|
||||
|
||||
14) Using Reported-by:, Tested-by: and Reviewed-by:
|
||||
14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
|
||||
|
||||
If this patch fixes a problem reported by somebody else, consider adding a
|
||||
Reported-by: tag to credit the reporter for their contribution. Please
|
||||
@@ -469,6 +468,13 @@ done on the patch. Reviewed-by: tags, when supplied by reviewers known to
|
||||
understand the subject area and to perform thorough reviews, will normally
|
||||
increase the likelihood of your patch getting into the kernel.
|
||||
|
||||
A Suggested-by: tag indicates that the patch idea is suggested by the person
|
||||
named and ensures credit to the person for the idea. Please note that this
|
||||
tag should not be added without the reporter's permission, especially if the
|
||||
idea was not posted in a public forum. That said, if we diligently credit our
|
||||
idea reporters, they will, hopefully, be inspired to help us again in the
|
||||
future.
|
||||
|
||||
|
||||
15) The canonical patch format
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
Frequently asked questions about the sunxi clock system
|
||||
=======================================================
|
||||
|
||||
This document contains useful bits of information that people tend to ask
|
||||
about the sunxi clock system, as well as accompanying ASCII art when adequate.
|
||||
|
||||
Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
|
||||
system?
|
||||
|
||||
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
|
||||
carelessly the system would stop functioning, but with the right
|
||||
steps, one can gate it and keep the system running. Consider this
|
||||
simplified suspend example:
|
||||
|
||||
While the system is operational, you would see something like
|
||||
|
||||
24MHz 32kHz
|
||||
|
|
||||
PLL1
|
||||
\
|
||||
\_ CPU Mux
|
||||
|
|
||||
[CPU]
|
||||
|
||||
When you are about to suspend, you switch the CPU Mux to the 32kHz
|
||||
oscillator:
|
||||
|
||||
24Mhz 32kHz
|
||||
| |
|
||||
PLL1 |
|
||||
/
|
||||
CPU Mux _/
|
||||
|
|
||||
[CPU]
|
||||
|
||||
Finally you can gate the main oscillator
|
||||
|
||||
32kHz
|
||||
|
|
||||
|
|
||||
/
|
||||
CPU Mux _/
|
||||
|
|
||||
[CPU]
|
||||
|
||||
Q: Were can I learn more about the sunxi clocks?
|
||||
|
||||
A: The linux-sunxi wiki contains a page documenting the clock registers,
|
||||
you can find it at
|
||||
|
||||
http://linux-sunxi.org/A10/CCM
|
||||
|
||||
The authoritative source for information at this time is the ccmu driver
|
||||
released by Allwinner, you can find it at
|
||||
|
||||
https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu
|
||||
@@ -32,14 +32,10 @@ Platform data for lp855x
|
||||
For supporting platform specific data, the lp855x platform data can be used.
|
||||
|
||||
* name : Backlight driver name. If it is not defined, default name is set.
|
||||
* mode : Brightness control mode. PWM or register based.
|
||||
* device_control : Value of DEVICE CONTROL register.
|
||||
* initial_brightness : Initial value of backlight brightness.
|
||||
* period_ns : Platform specific PWM period value. unit is nano.
|
||||
Only valid when brightness is pwm input mode.
|
||||
* load_new_rom_data :
|
||||
0 : use default configuration data
|
||||
1 : update values of eeprom or eprom registers on loading driver
|
||||
* size_program : Total size of lp855x_rom_data.
|
||||
* rom_data : List of new eeprom/eprom registers.
|
||||
|
||||
@@ -54,10 +50,8 @@ static struct lp855x_rom_data lp8552_eeprom_arr[] = {
|
||||
|
||||
static struct lp855x_platform_data lp8552_pdata = {
|
||||
.name = "lcd-bl",
|
||||
.mode = REGISTER_BASED,
|
||||
.device_control = I2C_CONFIG(LP8552),
|
||||
.initial_brightness = INITIAL_BRT,
|
||||
.load_new_rom_data = 1,
|
||||
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
|
||||
.rom_data = lp8552_eeprom_arr,
|
||||
};
|
||||
@@ -65,7 +59,6 @@ static struct lp855x_platform_data lp8552_pdata = {
|
||||
example 2) lp8556 platform data : pwm input mode with default rom data
|
||||
|
||||
static struct lp855x_platform_data lp8556_pdata = {
|
||||
.mode = PWM_BASED,
|
||||
.device_control = PWM_CONFIG(LP8556),
|
||||
.initial_brightness = INITIAL_BRT,
|
||||
.period_ns = 1000000,
|
||||
|
||||
@@ -442,7 +442,7 @@ You can attach the current shell task by echoing 0:
|
||||
You can use the cgroup.procs file instead of the tasks file to move all
|
||||
threads in a threadgroup at once. Echoing the PID of any task in a
|
||||
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
|
||||
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
||||
attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
||||
in the writing task's threadgroup.
|
||||
|
||||
Note: Since every task is always a member of exactly one cgroup in each
|
||||
@@ -580,6 +580,7 @@ propagation along the hierarchy. See the comment on
|
||||
cgroup_for_each_descendant_pre() for details.
|
||||
|
||||
void css_offline(struct cgroup *cgrp);
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
This is the counterpart of css_online() and called iff css_online()
|
||||
has succeeded on @cgrp. This signifies the beginning of the end of
|
||||
|
||||
@@ -13,9 +13,7 @@ either an integer or * for all. Access is a composition of r
|
||||
The root device cgroup starts with rwm to 'all'. A child device
|
||||
cgroup gets a copy of the parent. Administrators can then remove
|
||||
devices from the whitelist or add new entries. A child cgroup can
|
||||
never receive a device access which is denied by its parent. However
|
||||
when a device access is removed from a parent it will not also be
|
||||
removed from the child(ren).
|
||||
never receive a device access which is denied by its parent.
|
||||
|
||||
2. User Interface
|
||||
|
||||
@@ -50,3 +48,69 @@ task to a new cgroup. (Again we'll probably want to change that).
|
||||
|
||||
A cgroup may not be granted more permissions than the cgroup's
|
||||
parent has.
|
||||
|
||||
4. Hierarchy
|
||||
|
||||
device cgroups maintain hierarchy by making sure a cgroup never has more
|
||||
access permissions than its parent. Every time an entry is written to
|
||||
a cgroup's devices.deny file, all its children will have that entry removed
|
||||
from their whitelist and all the locally set whitelist entries will be
|
||||
re-evaluated. In case one of the locally set whitelist entries would provide
|
||||
more access than the cgroup's parent, it'll be removed from the whitelist.
|
||||
|
||||
Example:
|
||||
A
|
||||
/ \
|
||||
B
|
||||
|
||||
group behavior exceptions
|
||||
A allow "b 8:* rwm", "c 116:1 rw"
|
||||
B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
|
||||
|
||||
If a device is denied in group A:
|
||||
# echo "c 116:* r" > A/devices.deny
|
||||
it'll propagate down and after revalidating B's entries, the whitelist entry
|
||||
"c 116:2 rwm" will be removed:
|
||||
|
||||
group whitelist entries denied devices
|
||||
A all "b 8:* rwm", "c 116:* rw"
|
||||
B "c 1:3 rwm", "b 3:* rwm" all the rest
|
||||
|
||||
In case parent's exceptions change and local exceptions are not allowed
|
||||
anymore, they'll be deleted.
|
||||
|
||||
Notice that new whitelist entries will not be propagated:
|
||||
A
|
||||
/ \
|
||||
B
|
||||
|
||||
group whitelist entries denied devices
|
||||
A "c 1:3 rwm", "c 1:5 r" all the rest
|
||||
B "c 1:3 rwm", "c 1:5 r" all the rest
|
||||
|
||||
when adding "c *:3 rwm":
|
||||
# echo "c *:3 rwm" >A/devices.allow
|
||||
|
||||
the result:
|
||||
group whitelist entries denied devices
|
||||
A "c *:3 rwm", "c 1:5 r" all the rest
|
||||
B "c 1:3 rwm", "c 1:5 r" all the rest
|
||||
|
||||
but now it'll be possible to add new entries to B:
|
||||
# echo "c 2:3 rwm" >B/devices.allow
|
||||
# echo "c 50:3 r" >B/devices.allow
|
||||
or even
|
||||
# echo "c *:3 rwm" >B/devices.allow
|
||||
|
||||
Allowing or denying all by writing 'a' to devices.allow or devices.deny will
|
||||
not be possible once the device cgroups has children.
|
||||
|
||||
4.1 Hierarchy (internal implementation)
|
||||
|
||||
device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
|
||||
list of exceptions. The internal state is controlled using the same user
|
||||
interface to preserve compatibility with the previous whitelist-only
|
||||
implementation. Removal or addition of exceptions that will reduce the access
|
||||
to devices will be propagated down the hierarchy.
|
||||
For every propagated exception, the effective rules will be re-evaluated based
|
||||
on current parent's access rules.
|
||||
|
||||
@@ -40,6 +40,7 @@ Features:
|
||||
- soft limit
|
||||
- moving (recharging) account at moving a task is selectable.
|
||||
- usage threshold notifier
|
||||
- memory pressure notifier
|
||||
- oom-killer disable knob and oom-notifier
|
||||
- Root cgroup has no limit controls.
|
||||
|
||||
@@ -65,6 +66,7 @@ Brief summary of control files.
|
||||
memory.stat # show various statistics
|
||||
memory.use_hierarchy # set/show hierarchical account enabled
|
||||
memory.force_empty # trigger forced move charge to parent
|
||||
memory.pressure_level # set memory pressure notifications
|
||||
memory.swappiness # set/show swappiness parameter of vmscan
|
||||
(See sysctl's vm.swappiness)
|
||||
memory.move_charge_at_immigrate # set/show controls of moving charges
|
||||
@@ -762,7 +764,73 @@ At reading, current status of OOM is shown.
|
||||
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
|
||||
be stopped.)
|
||||
|
||||
11. TODO
|
||||
11. Memory Pressure
|
||||
|
||||
The pressure level notifications can be used to monitor the memory
|
||||
allocation cost; based on the pressure, applications can implement
|
||||
different strategies of managing their memory resources. The pressure
|
||||
levels are defined as following:
|
||||
|
||||
The "low" level means that the system is reclaiming memory for new
|
||||
allocations. Monitoring this reclaiming activity might be useful for
|
||||
maintaining cache level. Upon notification, the program (typically
|
||||
"Activity Manager") might analyze vmstat and act in advance (i.e.
|
||||
prematurely shutdown unimportant services).
|
||||
|
||||
The "medium" level means that the system is experiencing medium memory
|
||||
pressure, the system might be making swap, paging out active file caches,
|
||||
etc. Upon this event applications may decide to further analyze
|
||||
vmstat/zoneinfo/memcg or internal memory usage statistics and free any
|
||||
resources that can be easily reconstructed or re-read from a disk.
|
||||
|
||||
The "critical" level means that the system is actively thrashing, it is
|
||||
about to out of memory (OOM) or even the in-kernel OOM killer is on its
|
||||
way to trigger. Applications should do whatever they can to help the
|
||||
system. It might be too late to consult with vmstat or any other
|
||||
statistics, so it's advisable to take an immediate action.
|
||||
|
||||
The events are propagated upward until the event is handled, i.e. the
|
||||
events are not pass-through. Here is what this means: for example you have
|
||||
three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
|
||||
and C, and suppose group C experiences some pressure. In this situation,
|
||||
only group C will receive the notification, i.e. groups A and B will not
|
||||
receive it. This is done to avoid excessive "broadcasting" of messages,
|
||||
which disturbs the system and which is especially bad if we are low on
|
||||
memory or thrashing. So, organize the cgroups wisely, or propagate the
|
||||
events manually (or, ask us to implement the pass-through events,
|
||||
explaining why would you need them.)
|
||||
|
||||
The file memory.pressure_level is only used to setup an eventfd. To
|
||||
register a notification, an application must:
|
||||
|
||||
- create an eventfd using eventfd(2);
|
||||
- open memory.pressure_level;
|
||||
- write string like "<event_fd> <fd of memory.pressure_level> <level>"
|
||||
to cgroup.event_control.
|
||||
|
||||
Application will be notified through eventfd when memory pressure is at
|
||||
the specific level (or higher). Read/write operations to
|
||||
memory.pressure_level are no implemented.
|
||||
|
||||
Test:
|
||||
|
||||
Here is a small script example that makes a new cgroup, sets up a
|
||||
memory limit, sets up a notification in the cgroup and then makes child
|
||||
cgroup experience a critical pressure:
|
||||
|
||||
# cd /sys/fs/cgroup/memory/
|
||||
# mkdir foo
|
||||
# cd foo
|
||||
# cgroup_event_listener memory.pressure_level low &
|
||||
# echo 8000000 > memory.limit_in_bytes
|
||||
# echo 8000000 > memory.memsw.limit_in_bytes
|
||||
# echo $$ > tasks
|
||||
# dd if=/dev/zero | read x
|
||||
|
||||
(Expect a bunch of notifications, and eventually, the oom-killer will
|
||||
trigger.)
|
||||
|
||||
12. TODO
|
||||
|
||||
1. Add support for accounting huge pages (as a separate controller)
|
||||
2. Make per-cgroup scanner reclaim not-shared pages first
|
||||
|
||||
+13
-2
@@ -174,9 +174,9 @@ int clk_foo_enable(struct clk_hw *hw)
|
||||
};
|
||||
|
||||
Below is a matrix detailing which clk_ops are mandatory based upon the
|
||||
hardware capbilities of that clock. A cell marked as "y" means
|
||||
hardware capabilities of that clock. A cell marked as "y" means
|
||||
mandatory, a cell marked as "n" implies that either including that
|
||||
callback is invalid or otherwise uneccesary. Empty cells are either
|
||||
callback is invalid or otherwise unnecessary. Empty cells are either
|
||||
optional or must be evaluated on a case-by-case basis.
|
||||
|
||||
clock hardware characteristics
|
||||
@@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
|
||||
statically initialized clock data MUST be defined in a separate file
|
||||
from the logic that implements its ops. Basically separate the logic
|
||||
from the data and all is well.
|
||||
|
||||
Part 6 - Disabling clock gating of unused clocks
|
||||
|
||||
Sometimes during development it can be useful to be able to bypass the
|
||||
default disabling of unused clocks. For example, if drivers aren't enabling
|
||||
clocks properly but rely on them being on from the bootloader, bypassing
|
||||
the disabling means that the driver will remain functional while the issues
|
||||
are sorted out.
|
||||
|
||||
To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
|
||||
kernel.
|
||||
|
||||
@@ -30,6 +30,7 @@ The target is named "raid" and it accepts the following parameters:
|
||||
raid10 Various RAID10 inspired algorithms chosen by additional params
|
||||
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
|
||||
- RAID1E: Integrated Adjacent Stripe Mirroring
|
||||
- RAID1E: Integrated Offset Stripe Mirroring
|
||||
- and other similar RAID10 variants
|
||||
|
||||
Reference: Chapter 4 of
|
||||
@@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters:
|
||||
synchronisation state for each region.
|
||||
|
||||
[raid10_copies <# copies>]
|
||||
[raid10_format near]
|
||||
[raid10_format <near|far|offset>]
|
||||
These two options are used to alter the default layout of
|
||||
a RAID10 configuration. The number of copies is can be
|
||||
specified, but the default is 2. There are other variations
|
||||
to how the copies are laid down - the default and only current
|
||||
option is "near". Near copies are what most people think of
|
||||
with respect to mirroring. If these options are left
|
||||
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
|
||||
are given, then the layouts for 2, 3 and 4 devices are:
|
||||
specified, but the default is 2. There are also three
|
||||
variations to how the copies are laid down - the default
|
||||
is "near". Near copies are what most people think of with
|
||||
respect to mirroring. If these options are left unspecified,
|
||||
or 'raid10_copies 2' and/or 'raid10_format near' are given,
|
||||
then the layouts for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- ---------- --------------
|
||||
A1 A1 A1 A1 A2 A1 A1 A2 A2
|
||||
@@ -85,6 +86,33 @@ The target is named "raid" and it accepts the following parameters:
|
||||
3-device layout is what might be called a 'RAID1E - Integrated
|
||||
Adjacent Stripe Mirroring'.
|
||||
|
||||
If 'raid10_copies 2' and 'raid10_format far', then the layouts
|
||||
for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- -------------- --------------------
|
||||
A1 A2 A1 A2 A3 A1 A2 A3 A4
|
||||
A3 A4 A4 A5 A6 A5 A6 A7 A8
|
||||
A5 A6 A7 A8 A9 A9 A10 A11 A12
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
A2 A1 A3 A1 A2 A2 A1 A4 A3
|
||||
A4 A3 A6 A4 A5 A6 A5 A8 A7
|
||||
A6 A5 A9 A7 A8 A10 A9 A12 A11
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
|
||||
If 'raid10_copies 2' and 'raid10_format offset', then the
|
||||
layouts for 2, 3 and 4 devices are:
|
||||
2 drives 3 drives 4 drives
|
||||
-------- ------------ -----------------
|
||||
A1 A2 A1 A2 A3 A1 A2 A3 A4
|
||||
A2 A1 A3 A1 A2 A2 A1 A4 A3
|
||||
A3 A4 A4 A5 A6 A5 A6 A7 A8
|
||||
A4 A3 A6 A4 A5 A6 A5 A8 A7
|
||||
A5 A6 A7 A8 A9 A9 A10 A11 A12
|
||||
A6 A5 A9 A7 A8 A10 A9 A12 A11
|
||||
.. .. .. .. .. .. .. .. ..
|
||||
Here we see layouts closely akin to 'RAID1E - Integrated
|
||||
Offset Stripe Mirroring'.
|
||||
|
||||
<#raid_devs>: The number of devices composing the array.
|
||||
Each device consists of two entries. The first is the device
|
||||
containing the metadata (if any); the second is the one containing the
|
||||
@@ -142,3 +170,5 @@ Version History
|
||||
1.3.0 Added support for RAID 10
|
||||
1.3.1 Allow device replacement/rebuild for RAID 10
|
||||
1.3.2 Fix/improve redundancy checking for RAID10
|
||||
1.4.0 Non-functional change. Removes arg from mapping function.
|
||||
1.4.1 Add RAID10 "far" and "offset" algorithm support.
|
||||
|
||||
@@ -14,9 +14,19 @@ Required properties:
|
||||
- atmel,adc-status-register: Offset of the Interrupt Status Register
|
||||
- atmel,adc-trigger-register: Offset of the Trigger Register
|
||||
- atmel,adc-vref: Reference voltage in millivolts for the conversions
|
||||
- atmel,adc-res: List of resolution in bits supported by the ADC. List size
|
||||
must be two at least.
|
||||
- atmel,adc-res-names: Contains one identifier string for each resolution
|
||||
in atmel,adc-res property. "lowres" and "highres"
|
||||
identifiers are required.
|
||||
|
||||
Optional properties:
|
||||
- atmel,adc-use-external: Boolean to enable of external triggers
|
||||
- atmel,adc-use-res: String corresponding to an identifier from
|
||||
atmel,adc-res-names property. If not specified, the highest
|
||||
resolution will be used.
|
||||
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
|
||||
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
|
||||
|
||||
Optional trigger Nodes:
|
||||
- Required properties:
|
||||
@@ -40,6 +50,9 @@ adc0: adc@fffb0000 {
|
||||
atmel,adc-trigger-register = <0x08>;
|
||||
atmel,adc-use-external;
|
||||
atmel,adc-vref = <3300>;
|
||||
atmel,adc-res = <8 10>;
|
||||
atmel,adc-res-names = "lowres", "highres";
|
||||
atmel,adc-use-res = "lowres";
|
||||
|
||||
trigger@0 {
|
||||
trigger-name = "external-rising";
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
* Qualcomm SSBI
|
||||
|
||||
Some Qualcomm MSM devices contain a point-to-point serial bus used to
|
||||
communicate with a limited range of devices (mostly power management
|
||||
chips).
|
||||
|
||||
These require the following properties:
|
||||
|
||||
- compatible: "qcom,ssbi"
|
||||
|
||||
- qcom,controller-type
|
||||
indicates the SSBI bus variant the controller should use to talk
|
||||
with the slave device. This should be one of "ssbi", "ssbi2", or
|
||||
"pmic-arbiter". The type chosen is determined by the attached
|
||||
slave.
|
||||
|
||||
The slave device should be the single child node of the ssbi device
|
||||
with a compatible field.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user