mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 03:01:39 -04:00
It's been a relatively busy cycle for docs:
- A fair pile of RST conversions, many from Mauro. These create more
than the usual number of simple but annoying merge conflicts with other
trees, unfortunately. He has a lot more of these waiting on the wings
that, I think, will go to you directly later on.
- A new document on how to use merges and rebases in kernel repos, and one
on Spectre vulnerabilities.
- Various improvements to the build system, including automatic markup of
function() references because some people, for reasons I will never
understand, were of the opinion that :c:func:``function()`` is
unattractive and not fun to type.
- We now recommend using sphinx 1.7, but still support back to 1.4.
- Lots of smaller improvements, warning fixes, typo fixes, etc.
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAl0krAEPHGNvcmJldEBs
d24ubmV0AAoJEBdDWhNsDH5Yg98H/AuLqO9LpOgUjF4LhyjxGPdzJkY9RExSJ7km
gznyreLCZgFaJR+AY6YDsd4Jw6OJlPbu1YM/Qo3C3WrZVFVhgL/s2ebvBgCo50A8
raAFd8jTf4/mGCHnAqRotAPQ3mETJUk315B66lBJ6Oc+YdpRhwXWq8ZW2bJxInFF
3HDvoFgMf0KhLuMHUkkL0u3fxH1iA+KvDu8diPbJYFjOdOWENz/CV8wqdVkXRSEW
DJxIq89h/7d+hIG3d1I7Nw+gibGsAdjSjKv4eRKauZs4Aoxd1Gpl62z0JNk6aT3m
dtq4joLdwScydonXROD/Twn2jsu4xYTrPwVzChomElMowW/ZBBY=
=D0eO
-----END PGP SIGNATURE-----
Merge tag 'docs-5.3' of git://git.lwn.net/linux
Pull Documentation updates from Jonathan Corbet:
"It's been a relatively busy cycle for docs:
- A fair pile of RST conversions, many from Mauro. These create more
than the usual number of simple but annoying merge conflicts with
other trees, unfortunately. He has a lot more of these waiting on
the wings that, I think, will go to you directly later on.
- A new document on how to use merges and rebases in kernel repos,
and one on Spectre vulnerabilities.
- Various improvements to the build system, including automatic
markup of function() references because some people, for reasons I
will never understand, were of the opinion that
:c:func:``function()`` is unattractive and not fun to type.
- We now recommend using sphinx 1.7, but still support back to 1.4.
- Lots of smaller improvements, warning fixes, typo fixes, etc"
* tag 'docs-5.3' of git://git.lwn.net/linux: (129 commits)
docs: automarkup.py: ignore exceptions when seeking for xrefs
docs: Move binderfs to admin-guide
Disable Sphinx SmartyPants in HTML output
doc: RCU callback locks need only _bh, not necessarily _irq
docs: format kernel-parameters -- as code
Doc : doc-guide : Fix a typo
platform: x86: get rid of a non-existent document
Add the RCU docs to the core-api manual
Documentation: RCU: Add TOC tree hooks
Documentation: RCU: Rename txt files to rst
Documentation: RCU: Convert RCU UP systems to reST
Documentation: RCU: Convert RCU linked list to reST
Documentation: RCU: Convert RCU basic concepts to reST
docs: filesystems: Remove uneeded .rst extension on toctables
scripts/sphinx-pre-install: fix out-of-tree build
docs: zh_CN: submitting-drivers.rst: Remove a duplicated Documentation/
Documentation: PGP: update for newer HW devices
Documentation: Add section about CPU vulnerabilities for Spectre
Documentation: platform: Delete x86-laptop-drivers.txt
docs: Note that :c:func: should no longer be used
...
This commit is contained in:
commit
e9a83bd232
416 changed files with 12159 additions and 8581 deletions
|
|
@ -13,32 +13,32 @@ kill the processes associated with it and avoid using it in the future.
|
|||
|
||||
This patchkit implements the necessary infrastructure in the VM.
|
||||
|
||||
To quote the overview comment:
|
||||
To quote the overview comment::
|
||||
|
||||
* High level machine check handler. Handles pages reported by the
|
||||
* hardware as being corrupted usually due to a 2bit ECC memory or cache
|
||||
* failure.
|
||||
*
|
||||
* This focusses on pages detected as corrupted in the background.
|
||||
* When the current CPU tries to consume corruption the currently
|
||||
* running process can just be killed directly instead. This implies
|
||||
* that if the error cannot be handled for some reason it's safe to
|
||||
* just ignore it because no corruption has been consumed yet. Instead
|
||||
* when that happens another machine check will happen.
|
||||
*
|
||||
* Handles page cache pages in various states. The tricky part
|
||||
* here is that we can access any page asynchronous to other VM
|
||||
* users, because memory failures could happen anytime and anywhere,
|
||||
* possibly violating some of their assumptions. This is why this code
|
||||
* has to be extremely careful. Generally it tries to use normal locking
|
||||
* rules, as in get the standard locks, even if that means the
|
||||
* error handling takes potentially a long time.
|
||||
*
|
||||
* Some of the operations here are somewhat inefficient and have non
|
||||
* linear algorithmic complexity, because the data structures have not
|
||||
* been optimized for this case. This is in particular the case
|
||||
* for the mapping from a vma to a process. Since this case is expected
|
||||
* to be rare we hope we can get away with this.
|
||||
High level machine check handler. Handles pages reported by the
|
||||
hardware as being corrupted usually due to a 2bit ECC memory or cache
|
||||
failure.
|
||||
|
||||
This focusses on pages detected as corrupted in the background.
|
||||
When the current CPU tries to consume corruption the currently
|
||||
running process can just be killed directly instead. This implies
|
||||
that if the error cannot be handled for some reason it's safe to
|
||||
just ignore it because no corruption has been consumed yet. Instead
|
||||
when that happens another machine check will happen.
|
||||
|
||||
Handles page cache pages in various states. The tricky part
|
||||
here is that we can access any page asynchronous to other VM
|
||||
users, because memory failures could happen anytime and anywhere,
|
||||
possibly violating some of their assumptions. This is why this code
|
||||
has to be extremely careful. Generally it tries to use normal locking
|
||||
rules, as in get the standard locks, even if that means the
|
||||
error handling takes potentially a long time.
|
||||
|
||||
Some of the operations here are somewhat inefficient and have non
|
||||
linear algorithmic complexity, because the data structures have not
|
||||
been optimized for this case. This is in particular the case
|
||||
for the mapping from a vma to a process. Since this case is expected
|
||||
to be rare we hope we can get away with this.
|
||||
|
||||
The code consists of a the high level handler in mm/memory-failure.c,
|
||||
a new page poison bit and various checks in the VM to handle poisoned
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ Local allocation will tend to keep subsequent access to the allocated memory
|
|||
as long as the task on whose behalf the kernel allocated some memory does not
|
||||
later migrate away from that memory. The Linux scheduler is aware of the
|
||||
NUMA topology of the platform--embodied in the "scheduling domains" data
|
||||
structures [see Documentation/scheduler/sched-domains.txt]--and the scheduler
|
||||
structures [see Documentation/scheduler/sched-domains.rst]--and the scheduler
|
||||
attempts to minimize task migration to distant scheduling domains. However,
|
||||
the scheduler does not take a task's NUMA footprint into account directly.
|
||||
Thus, under sufficient imbalance, tasks can migrate between nodes, remote
|
||||
|
|
|
|||
Loading…
Reference in a new issue