mirror of
https://github.com/a52xq-dev/kernel.git
synced 2026-10-18 21:58:11 +07:00
Linux 4.16-rc5
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAlqlyPEeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGNa0H/RIa/StQuYu/SBwa JRqQFmkIsx+gG+FyamJrqGzRfyjounES8PbfyaN3cCrzYgeRwMp1U/bZW6/l5tkb OjTtrCJ6CJaa21fC/7aqn3rhejHciKyk83EinMu5WjDpsQcaF2xKr3SaPa62Ja24 fhawKq3CnUa+OUuAbicVX8yn4viUB6x8FjSN/IWfp3Cs4IBR7SGxxD7A4MET9FbQ 5OOu0al8ly9QeCggTtJyk+cApeLfexEBTbUur9gm7GcH9jhUtJSyZCZsDJx6M2yb CwdgF4fyk58c1fuHvTFb0AdUns55ba3nicybRHHMVbDpZIG9v4/M1yJETHHf5cD7 t3rFjrY= =+Ldf -----END PGP SIGNATURE----- Merge tag 'v4.16-rc5' into devel Linux 4.16-rc5 merged into the GPIO devel branch to resolve a nasty conflict between fixes and devel in the RCAR driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This commit is contained in:
commit
95260c17b2
1242 changed files with 13451 additions and 8414 deletions
4
.gitignore
vendored
4
.gitignore
vendored
|
|
@ -127,3 +127,7 @@ all.config
|
|||
|
||||
# Kdevelop4
|
||||
*.kdev4
|
||||
|
||||
#Automatically generated by ASN.1 compiler
|
||||
net/ipv4/netfilter/nf_nat_snmp_basic-asn1.c
|
||||
net/ipv4/netfilter/nf_nat_snmp_basic-asn1.h
|
||||
|
|
|
|||
39
Documentation/ABI/testing/sysfs-devices-platform-dock
Normal file
39
Documentation/ABI/testing/sysfs-devices-platform-dock
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
What: /sys/devices/platform/dock.N/docked
|
||||
Date: Dec, 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Value 1 or 0 indicates whether the software believes the
|
||||
laptop is docked in a docking station.
|
||||
|
||||
What: /sys/devices/platform/dock.N/undock
|
||||
Date: Dec, 2006
|
||||
KernelVersion: 2.6.19
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(WO) Writing to this file causes the software to initiate an
|
||||
undock request to the firmware.
|
||||
|
||||
What: /sys/devices/platform/dock.N/uid
|
||||
Date: Feb, 2007
|
||||
KernelVersion: v2.6.21
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Displays the docking station the laptop is docked to.
|
||||
|
||||
What: /sys/devices/platform/dock.N/flags
|
||||
Date: May, 2007
|
||||
KernelVersion: v2.6.21
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Show dock station flags, useful for checking if undock
|
||||
request has been made by the user (from the immediate_undock
|
||||
option).
|
||||
|
||||
What: /sys/devices/platform/dock.N/type
|
||||
Date: Aug, 2008
|
||||
KernelVersion: v2.6.27
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Display the dock station type- dock_station, ata_bay or
|
||||
battery_bay.
|
||||
|
|
@ -108,6 +108,8 @@ Description: CPU topology files that describe a logical CPU's relationship
|
|||
|
||||
What: /sys/devices/system/cpu/cpuidle/current_driver
|
||||
/sys/devices/system/cpu/cpuidle/current_governer_ro
|
||||
/sys/devices/system/cpu/cpuidle/available_governors
|
||||
/sys/devices/system/cpu/cpuidle/current_governor
|
||||
Date: September 2007
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Discover cpuidle policy and mechanism
|
||||
|
|
@ -119,13 +121,84 @@ Description: Discover cpuidle policy and mechanism
|
|||
Idle policy (governor) is differentiated from idle mechanism
|
||||
(driver)
|
||||
|
||||
current_driver: displays current idle mechanism
|
||||
current_driver: (RO) displays current idle mechanism
|
||||
|
||||
current_governor_ro: displays current idle policy
|
||||
current_governor_ro: (RO) displays current idle policy
|
||||
|
||||
With the cpuidle_sysfs_switch boot option enabled (meant for
|
||||
developer testing), the following three attributes are visible
|
||||
instead:
|
||||
|
||||
current_driver: same as described above
|
||||
|
||||
available_governors: (RO) displays a space separated list of
|
||||
available governors
|
||||
|
||||
current_governor: (RW) displays current idle policy. Users can
|
||||
switch the governor at runtime by writing to this file.
|
||||
|
||||
See files in Documentation/cpuidle/ for more information.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/name
|
||||
/sys/devices/system/cpu/cpuX/cpuidle/stateN/latency
|
||||
/sys/devices/system/cpu/cpuX/cpuidle/stateN/power
|
||||
/sys/devices/system/cpu/cpuX/cpuidle/stateN/time
|
||||
/sys/devices/system/cpu/cpuX/cpuidle/stateN/usage
|
||||
Date: September 2007
|
||||
KernelVersion: v2.6.24
|
||||
Contact: Linux power management list <linux-pm@vger.kernel.org>
|
||||
Description:
|
||||
The directory /sys/devices/system/cpu/cpuX/cpuidle contains per
|
||||
logical CPU specific cpuidle information for each online cpu X.
|
||||
The processor idle states which are available for use have the
|
||||
following attributes:
|
||||
|
||||
name: (RO) Name of the idle state (string).
|
||||
|
||||
latency: (RO) The latency to exit out of this idle state (in
|
||||
microseconds).
|
||||
|
||||
power: (RO) The power consumed while in this idle state (in
|
||||
milliwatts).
|
||||
|
||||
time: (RO) The total time spent in this idle state (in microseconds).
|
||||
|
||||
usage: (RO) Number of times this state was entered (a count).
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/desc
|
||||
Date: February 2008
|
||||
KernelVersion: v2.6.25
|
||||
Contact: Linux power management list <linux-pm@vger.kernel.org>
|
||||
Description:
|
||||
(RO) A small description about the idle state (string).
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/disable
|
||||
Date: March 2012
|
||||
KernelVersion: v3.10
|
||||
Contact: Linux power management list <linux-pm@vger.kernel.org>
|
||||
Description:
|
||||
(RW) Option to disable this idle state (bool). The behavior and
|
||||
the effect of the disable variable depends on the implementation
|
||||
of a particular governor. In the ladder governor, for example,
|
||||
it is not coherent, i.e. if one is disabling a light state, then
|
||||
all deeper states are disabled as well, but the disable variable
|
||||
does not reflect it. Likewise, if one enables a deep state but a
|
||||
lighter state still is disabled, then this has no effect.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/residency
|
||||
Date: March 2014
|
||||
KernelVersion: v3.15
|
||||
Contact: Linux power management list <linux-pm@vger.kernel.org>
|
||||
Description:
|
||||
(RO) Display the target residency i.e. the minimum amount of
|
||||
time (in microseconds) this cpu should spend in this idle state
|
||||
to make the transition worth the effort.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/cpufreq/*
|
||||
Date: pre-git history
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
|
|
|
|||
40
Documentation/ABI/testing/sysfs-platform-dptf
Normal file
40
Documentation/ABI/testing/sysfs-platform-dptf
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
What: /sys/bus/platform/devices/INT3407:00/dptf_power/charger_type
|
||||
Date: Jul, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) The charger type - Traditional, Hybrid or NVDC.
|
||||
|
||||
What: /sys/bus/platform/devices/INT3407:00/dptf_power/adapter_rating_mw
|
||||
Date: Jul, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Adapter rating in milliwatts (the maximum Adapter power).
|
||||
Must be 0 if no AC Adaptor is plugged in.
|
||||
|
||||
What: /sys/bus/platform/devices/INT3407:00/dptf_power/max_platform_power_mw
|
||||
Date: Jul, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Maximum platform power that can be supported by the battery
|
||||
in milliwatts.
|
||||
|
||||
What: /sys/bus/platform/devices/INT3407:00/dptf_power/platform_power_source
|
||||
Date: Jul, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) Display the platform power source
|
||||
0x00 = DC
|
||||
0x01 = AC
|
||||
0x02 = USB
|
||||
0x03 = Wireless Charger
|
||||
|
||||
What: /sys/bus/platform/devices/INT3407:00/dptf_power/battery_steady_power
|
||||
Date: Jul, 2016
|
||||
KernelVersion: v4.10
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description:
|
||||
(RO) The maximum sustained power for battery in milliwatts.
|
||||
|
|
@ -570,7 +570,9 @@ your driver if they're helpful, or just use plain hex constants.
|
|||
The device IDs are arbitrary hex numbers (vendor controlled) and normally used
|
||||
only in a single location, the pci_device_id table.
|
||||
|
||||
Please DO submit new vendor/device IDs to http://pciids.sourceforge.net/.
|
||||
Please DO submit new vendor/device IDs to http://pci-ids.ucw.cz/.
|
||||
There are mirrors of the pci.ids file at http://pciids.sourceforge.net/
|
||||
and https://github.com/pciutils/pciids.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -152,6 +152,11 @@ OCXL_IOCTL_IRQ_SET_FD:
|
|||
Associate an event fd to an AFU interrupt so that the user process
|
||||
can be notified when the AFU sends an interrupt.
|
||||
|
||||
OCXL_IOCTL_GET_METADATA:
|
||||
|
||||
Obtains configuration information from the card, such at the size of
|
||||
MMIO areas, the AFU version, and the PASID for the current context.
|
||||
|
||||
|
||||
mmap
|
||||
----
|
||||
|
|
|
|||
|
|
@ -58,7 +58,12 @@ Like with atomic_t, the rule of thumb is:
|
|||
|
||||
- RMW operations that have a return value are fully ordered.
|
||||
|
||||
Except for test_and_set_bit_lock() which has ACQUIRE semantics and
|
||||
- RMW operations that are conditional are unordered on FAILURE,
|
||||
otherwise the above rules apply. In the case of test_and_{}_bit() operations,
|
||||
if the bit in memory is unchanged by the operation then it is deemed to have
|
||||
failed.
|
||||
|
||||
Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics and
|
||||
clear_bit_unlock() which has RELEASE semantics.
|
||||
|
||||
Since a platform only has a single means of achieving atomic operations
|
||||
|
|
|
|||
18
Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt
Normal file
18
Documentation/devicetree/bindings/auxdisplay/arm-charlcd.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
ARM Versatile Character LCD
|
||||
-----------------------------------------------------
|
||||
This binding defines the character LCD interface found on ARM Versatile AB
|
||||
and PB reference platforms.
|
||||
|
||||
Required properties:
|
||||
- compatible : "arm,versatile-clcd"
|
||||
- reg : Location and size of character LCD registers
|
||||
|
||||
Optional properties:
|
||||
- interrupts - single interrupt for character LCD. The character LCD can
|
||||
operate in polled mode without an interrupt.
|
||||
|
||||
Example:
|
||||
lcd@10008000 {
|
||||
compatible = "arm,versatile-lcd";
|
||||
reg = <0x10008000 0x1000>;
|
||||
};
|
||||
|
|
@ -11,7 +11,11 @@ Required properties:
|
|||
interrupts.
|
||||
|
||||
Optional properties:
|
||||
- clocks: Optional reference to the clock used by the XOR engine.
|
||||
- clocks: Optional reference to the clocks used by the XOR engine.
|
||||
- clock-names: mandatory if there is a second clock, in this case the
|
||||
name must be "core" for the first clock and "reg" for the second
|
||||
one
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ Required properties:
|
|||
|
||||
"catalyst",
|
||||
"microchip",
|
||||
"nxp",
|
||||
"ramtron",
|
||||
"renesas",
|
||||
"nxp",
|
||||
"st",
|
||||
|
||||
Some vendors use different model names for chips which are just
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@ Required properties:
|
|||
- "renesas,irqc-r8a7794" (R-Car E2)
|
||||
- "renesas,intc-ex-r8a7795" (R-Car H3)
|
||||
- "renesas,intc-ex-r8a7796" (R-Car M3-W)
|
||||
- "renesas,intc-ex-r8a77965" (R-Car M3-N)
|
||||
- "renesas,intc-ex-r8a77970" (R-Car V3M)
|
||||
- "renesas,intc-ex-r8a77995" (R-Car D3)
|
||||
- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Required properties:
|
|||
- "renesas,etheravb-r8a7795" for the R8A7795 SoC.
|
||||
- "renesas,etheravb-r8a7796" for the R8A7796 SoC.
|
||||
- "renesas,etheravb-r8a77970" for the R8A77970 SoC.
|
||||
- "renesas,etheravb-r8a77980" for the R8A77980 SoC.
|
||||
- "renesas,etheravb-r8a77995" for the R8A77995 SoC.
|
||||
- "renesas,etheravb-rcar-gen3" as a fallback for the above
|
||||
R-Car Gen3 devices.
|
||||
|
|
|
|||
8
Documentation/devicetree/bindings/power/mti,mips-cpc.txt
Normal file
8
Documentation/devicetree/bindings/power/mti,mips-cpc.txt
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
Binding for MIPS Cluster Power Controller (CPC).
|
||||
|
||||
This binding allows a system to specify where the CPC registers are
|
||||
located.
|
||||
|
||||
Required properties:
|
||||
compatible : Should be "mti,mips-cpc".
|
||||
regs: Should describe the address & size of the CPC register region.
|
||||
|
|
@ -60,7 +60,7 @@ Examples
|
|||
#size-cells = <0>;
|
||||
|
||||
button@1 {
|
||||
debounce_interval = <50>;
|
||||
debounce-interval = <50>;
|
||||
wakeup-source;
|
||||
linux,code = <116>;
|
||||
label = "POWER";
|
||||
|
|
|
|||
|
|
@ -22,7 +22,32 @@ Optional properties:
|
|||
- clocks : thermal sensor's clock source.
|
||||
|
||||
Example:
|
||||
ocotp: ocotp@21bc000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "fsl,imx6sx-ocotp", "syscon";
|
||||
reg = <0x021bc000 0x4000>;
|
||||
clocks = <&clks IMX6SX_CLK_OCOTP>;
|
||||
|
||||
tempmon_calib: calib@38 {
|
||||
reg = <0x38 4>;
|
||||
};
|
||||
|
||||
tempmon_temp_grade: temp-grade@20 {
|
||||
reg = <0x20 4>;
|
||||
};
|
||||
};
|
||||
|
||||
tempmon: tempmon {
|
||||
compatible = "fsl,imx6sx-tempmon", "fsl,imx6q-tempmon";
|
||||
interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
|
||||
fsl,tempmon = <&anatop>;
|
||||
nvmem-cells = <&tempmon_calib>, <&tempmon_temp_grade>;
|
||||
nvmem-cell-names = "calib", "temp_grade";
|
||||
clocks = <&clks IMX6SX_CLK_PLL3_USB_OTG>;
|
||||
};
|
||||
|
||||
Legacy method (Deprecated):
|
||||
tempmon {
|
||||
compatible = "fsl,imx6q-tempmon";
|
||||
fsl,tempmon = <&anatop>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,62 @@
|
|||
#
|
||||
# Feature name: membarrier-sync-core
|
||||
# Kconfig: ARCH_HAS_MEMBARRIER_SYNC_CORE
|
||||
# description: arch supports core serializing membarrier
|
||||
#
|
||||
# Architecture requirements
|
||||
#
|
||||
# * arm64
|
||||
#
|
||||
# Rely on eret context synchronization when returning from IPI handler, and
|
||||
# when returning to user-space.
|
||||
#
|
||||
# * x86
|
||||
#
|
||||
# x86-32 uses IRET as return from interrupt, which takes care of the IPI.
|
||||
# However, it uses both IRET and SYSEXIT to go back to user-space. The IRET
|
||||
# instruction is core serializing, but not SYSEXIT.
|
||||
#
|
||||
# x86-64 uses IRET as return from interrupt, which takes care of the IPI.
|
||||
# However, it can return to user-space through either SYSRETL (compat code),
|
||||
# SYSRETQ, or IRET.
|
||||
#
|
||||
# Given that neither SYSRET{L,Q}, nor SYSEXIT, are core serializing, we rely
|
||||
# instead on write_cr3() performed by switch_mm() to provide core serialization
|
||||
# after changing the current mm, and deal with the special case of kthread ->
|
||||
# uthread (temporarily keeping current mm into active_mm) by issuing a
|
||||
# sync_core_before_usermode() in that specific case.
|
||||
#
|
||||
-----------------------
|
||||
| arch |status|
|
||||
-----------------------
|
||||
| alpha: | TODO |
|
||||
| arc: | TODO |
|
||||
| arm: | TODO |
|
||||
| arm64: | ok |
|
||||
| blackfin: | TODO |
|
||||
| c6x: | TODO |
|
||||
| cris: | TODO |
|
||||
| frv: | TODO |
|
||||
| h8300: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
| m32r: | TODO |
|
||||
| m68k: | TODO |
|
||||
| metag: | TODO |
|
||||
| microblaze: | TODO |
|
||||
| mips: | TODO |
|
||||
| mn10300: | TODO |
|
||||
| nios2: | TODO |
|
||||
| openrisc: | TODO |
|
||||
| parisc: | TODO |
|
||||
| powerpc: | TODO |
|
||||
| s390: | TODO |
|
||||
| score: | TODO |
|
||||
| sh: | TODO |
|
||||
| sparc: | TODO |
|
||||
| tile: | TODO |
|
||||
| um: | TODO |
|
||||
| unicore32: | TODO |
|
||||
| x86: | ok |
|
||||
| xtensa: | TODO |
|
||||
-----------------------
|
||||
|
|
@ -3,4 +3,4 @@
|
|||
==================================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/tve200/tve200_drv.c
|
||||
:doc: Faraday TV Encoder 200
|
||||
:doc: Faraday TV Encoder TVE200 DRM Driver
|
||||
|
|
|
|||
|
|
@ -28,8 +28,10 @@ Supported adapters:
|
|||
* Intel Wildcat Point (PCH)
|
||||
* Intel Wildcat Point-LP (PCH)
|
||||
* Intel BayTrail (SOC)
|
||||
* Intel Braswell (SOC)
|
||||
* Intel Sunrise Point-H (PCH)
|
||||
* Intel Sunrise Point-LP (PCH)
|
||||
* Intel Kaby Lake-H (PCH)
|
||||
* Intel DNV (SOC)
|
||||
* Intel Broxton (SOC)
|
||||
* Intel Lewisburg (PCH)
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
|
|||
|
||||
- If you don't have an HCDP, the kernel doesn't know where
|
||||
your console lives until the driver discovers serial
|
||||
devices. Use "console=uart, io,0x3f8" (or appropriate
|
||||
devices. Use "console=uart,io,0x3f8" (or appropriate
|
||||
address for your machine).
|
||||
|
||||
Kernel and init script output works fine, but no "login:" prompt:
|
||||
|
|
|
|||
|
|
@ -21,37 +21,23 @@ Implementation
|
|||
--------------
|
||||
|
||||
Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h
|
||||
and implemented in kernel/locking/mutex.c. These locks use a three
|
||||
state atomic counter (->count) to represent the different possible
|
||||
transitions that can occur during the lifetime of a lock:
|
||||
|
||||
1: unlocked
|
||||
0: locked, no waiters
|
||||
negative: locked, with potential waiters
|
||||
|
||||
In its most basic form it also includes a wait-queue and a spinlock
|
||||
that serializes access to it. CONFIG_SMP systems can also include
|
||||
a pointer to the lock task owner (->owner) as well as a spinner MCS
|
||||
lock (->osq), both described below in (ii).
|
||||
and implemented in kernel/locking/mutex.c. These locks use an atomic variable
|
||||
(->owner) to keep track of the lock state during its lifetime. Field owner
|
||||
actually contains 'struct task_struct *' to the current lock owner and it is
|
||||
therefore NULL if not currently owned. Since task_struct pointers are aligned
|
||||
at at least L1_CACHE_BYTES, low bits (3) are used to store extra state (e.g.,
|
||||
if waiter list is non-empty). In its most basic form it also includes a
|
||||
wait-queue and a spinlock that serializes access to it. Furthermore,
|
||||
CONFIG_MUTEX_SPIN_ON_OWNER=y systems use a spinner MCS lock (->osq), described
|
||||
below in (ii).
|
||||
|
||||
When acquiring a mutex, there are three possible paths that can be
|
||||
taken, depending on the state of the lock:
|
||||
|
||||
(i) fastpath: tries to atomically acquire the lock by decrementing the
|
||||
counter. If it was already taken by another task it goes to the next
|
||||
possible path. This logic is architecture specific. On x86-64, the
|
||||
locking fastpath is 2 instructions:
|
||||
|
||||
0000000000000e10 <mutex_lock>:
|
||||
e21: f0 ff 0b lock decl (%rbx)
|
||||
e24: 79 08 jns e2e <mutex_lock+0x1e>
|
||||
|
||||
the unlocking fastpath is equally tight:
|
||||
|
||||
0000000000000bc0 <mutex_unlock>:
|
||||
bc8: f0 ff 07 lock incl (%rdi)
|
||||
bcb: 7f 0a jg bd7 <mutex_unlock+0x17>
|
||||
|
||||
(i) fastpath: tries to atomically acquire the lock by cmpxchg()ing the owner with
|
||||
the current task. This only works in the uncontended case (cmpxchg() checks
|
||||
against 0UL, so all 3 state bits above have to be 0). If the lock is
|
||||
contended it goes to the next possible path.
|
||||
|
||||
(ii) midpath: aka optimistic spinning, tries to spin for acquisition
|
||||
while the lock owner is running and there are no other tasks ready
|
||||
|
|
@ -143,11 +129,10 @@ Test if the mutex is taken:
|
|||
Disadvantages
|
||||
-------------
|
||||
|
||||
Unlike its original design and purpose, 'struct mutex' is larger than
|
||||
most locks in the kernel. E.g: on x86-64 it is 40 bytes, almost twice
|
||||
as large as 'struct semaphore' (24 bytes) and tied, along with rwsems,
|
||||
for the largest lock in the kernel. Larger structure sizes mean more
|
||||
CPU cache and memory footprint.
|
||||
Unlike its original design and purpose, 'struct mutex' is among the largest
|
||||
locks in the kernel. E.g: on x86-64 it is 32 bytes, where 'struct semaphore'
|
||||
is 24 bytes and rw_semaphore is 40 bytes. Larger structure sizes mean more CPU
|
||||
cache and memory footprint.
|
||||
|
||||
When to use mutexes
|
||||
-------------------
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue