Merge drm/drm-next into drm-intel-next-queued (e205ceeb) · Commits · jan.koester / Linux

.mailmap

+7 −1

CREDITS

+4 −0

Original line number	Original line	Diff line number	Diff line
	@@ -1637,6 +1637,10 @@ S: Panoramastrasse 18
	S: D-69126 Heidelberg		S: D-69126 Heidelberg
	S: Germany		S: Germany

			N: Simon Horman
			M: horms@verge.net.au
			D: Renesas ARM/ARM64 SoC maintainer

	N: Christopher Horn		N: Christopher Horn
	E: chorn@warwick.net		E: chorn@warwick.net
	D: Miscellaneous sysctl hacks		D: Miscellaneous sysctl hacks

Documentation/admin-guide/cgroup-v2.rst

+14 −6

Original line number	Original line	Diff line number	Diff line
	@@ -615,8 +615,8 @@ on an IO device and is an example of this type.
	Protections		Protections
	-----------		-----------

	A cgroup is protected to be allocated upto the configured amount of		A cgroup is protected upto the configured amount of the resource
	the resource if the usages of all its ancestors are under their		as long as the usages of all its ancestors are under their
	protected levels. Protections can be hard guarantees or best effort		protected levels. Protections can be hard guarantees or best effort
	soft boundaries. Protections can also be over-committed in which case		soft boundaries. Protections can also be over-committed in which case
	only upto the amount available to the parent is protected among		only upto the amount available to the parent is protected among
	@@ -1096,7 +1096,10 @@ PAGE_SIZE multiple when read back.
	is within its effective min boundary, the cgroup's memory		is within its effective min boundary, the cgroup's memory
	won't be reclaimed under any conditions. If there is no		won't be reclaimed under any conditions. If there is no
	unprotected reclaimable memory available, OOM killer		unprotected reclaimable memory available, OOM killer
	is invoked.		is invoked. Above the effective min boundary (or
			effective low boundary if it is higher), pages are reclaimed
			proportionally to the overage, reducing reclaim pressure for
			smaller overages.

	Effective min boundary is limited by memory.min values of		Effective min boundary is limited by memory.min values of
	all ancestor cgroups. If there is memory.min overcommitment		all ancestor cgroups. If there is memory.min overcommitment
	@@ -1118,7 +1121,10 @@ PAGE_SIZE multiple when read back.
	Best-effort memory protection. If the memory usage of a		Best-effort memory protection. If the memory usage of a
	cgroup is within its effective low boundary, the cgroup's		cgroup is within its effective low boundary, the cgroup's
	memory won't be reclaimed unless memory can be reclaimed		memory won't be reclaimed unless memory can be reclaimed
	from unprotected cgroups.		from unprotected cgroups. Above the effective low boundary (or
			effective min boundary if it is higher), pages are reclaimed
			proportionally to the overage, reducing reclaim pressure for
			smaller overages.

	Effective low boundary is limited by memory.low values of		Effective low boundary is limited by memory.low values of
	all ancestor cgroups. If there is memory.low overcommitment		all ancestor cgroups. If there is memory.low overcommitment
	@@ -2482,8 +2488,10 @@ system performance due to overreclaim, to the point where the feature
	becomes self-defeating.		becomes self-defeating.

	The memory.low boundary on the other hand is a top-down allocated		The memory.low boundary on the other hand is a top-down allocated
	reserve. A cgroup enjoys reclaim protection when it's within its low,		reserve. A cgroup enjoys reclaim protection when it's within its
	which makes delegation of subtrees possible.		effective low, which makes delegation of subtrees possible. It also
			enjoys having reclaim pressure proportional to its overage when
			above its effective low.

	The original high boundary, the hard limit, is defined as a strict		The original high boundary, the hard limit, is defined as a strict
	limit that can not budge, even if the OOM killer has to be called.		limit that can not budge, even if the OOM killer has to be called.

Documentation/admin-guide/kernel-parameters.txt

+4 −0

Original line number	Original line	Diff line number	Diff line
	@@ -5302,6 +5302,10 @@
	the unplug protocol		the unplug protocol
	never -- do not unplug even if version check succeeds		never -- do not unplug even if version check succeeds

			xen_legacy_crash [X86,XEN]
			Crash from Xen panic notifier, without executing late
			panic() code such as dumping handler.

	xen_nopvspin [X86,XEN]		xen_nopvspin [X86,XEN]
	Disables the ticketlock slowpath using Xen PV		Disables the ticketlock slowpath using Xen PV
	optimizations.		optimizations.

Documentation/arm64/memory.rst

+8 −1

Original line number	Original line	Diff line number	Diff line
	@@ -154,11 +154,18 @@ return virtual addresses to userspace from a 48-bit range.

	Software can "opt-in" to receiving VAs from a 52-bit space by		Software can "opt-in" to receiving VAs from a 52-bit space by
	specifying an mmap hint parameter that is larger than 48-bit.		specifying an mmap hint parameter that is larger than 48-bit.

	For example:		For example:

			.. code-block:: c

	maybe_high_address = mmap(~0UL, size, prot, flags,...);		maybe_high_address = mmap(~0UL, size, prot, flags,...);

	It is also possible to build a debug kernel that returns addresses		It is also possible to build a debug kernel that returns addresses
	from a 52-bit space by enabling the following kernel config options:		from a 52-bit space by enabling the following kernel config options:

			.. code-block:: sh

	CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y		CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y

	Note that this option is only intended for debugging applications		Note that this option is only intended for debugging applications

Original line number	Original line	Diff line number	Diff line
	@@ -108,6 +108,10 @@ Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
	Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>		Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
	Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>		Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
	<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>		<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
			Jayachandran C <c.jayachandran@gmail.com> <jayachandranc@netlogicmicro.com>
			Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
			Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
			Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
	Jean Tourrilhes <jt@hpl.hp.com>		Jean Tourrilhes <jt@hpl.hp.com>
	<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>		<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
	Jeff Garzik <jgarzik@pretzel.yyz.us>		Jeff Garzik <jgarzik@pretzel.yyz.us>
	@@ -196,7 +200,8 @@ Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
	Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>		Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
	Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>		Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
	Patrick Mochel <mochel@digitalimplant.org>		Patrick Mochel <mochel@digitalimplant.org>
	Paul Burton <paul.burton@mips.com> <paul.burton@imgtec.com>		Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com>
			Paul Burton <paulburton@kernel.org> <paul.burton@mips.com>
	Peter A Jonsson <pj@ludd.ltu.se>		Peter A Jonsson <pj@ludd.ltu.se>
	Peter Oruba <peter@oruba.de>		Peter Oruba <peter@oruba.de>
	Peter Oruba <peter.oruba@amd.com>		Peter Oruba <peter.oruba@amd.com>
	@@ -229,6 +234,7 @@ Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
	Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>		Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>
	Shuah Khan <shuah@kernel.org> <shuahkh@osg.samsung.com>		Shuah Khan <shuah@kernel.org> <shuahkh@osg.samsung.com>
	Shuah Khan <shuah@kernel.org> <shuah.kh@samsung.com>		Shuah Khan <shuah@kernel.org> <shuah.kh@samsung.com>
			Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
	Simon Kelley <simon@thekelleys.org.uk>		Simon Kelley <simon@thekelleys.org.uk>
	Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>		Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
	Stephen Hemminger <shemminger@osdl.org>		Stephen Hemminger <shemminger@osdl.org>