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 ...
Šī revīzija ir iekļauta:
@@ -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
|
||||
|
Atsaukties uz šo jaunā problēmā
Block a user