Merge branch 'akpm' (patches from Andrew)
Merge more updates from Andrew Morton: - most of the rest of MM (memcg, hugetlb, vmscan, proc, compaction, mempolicy, oom-kill, hugetlbfs, migration, thp, cma, util, memory-hotplug, cleanups, uaccess, migration, gup, pagemap), - various other subsystems (alpha, misc, sparse, bitmap, lib, bitops, checkpatch, autofs, minix, nilfs, ufs, fat, signals, kmod, coredump, exec, kdump, rapidio, panic, kcov, kgdb, ipc). * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (164 commits) mm/gup: remove task_struct pointer for all gup code mm: clean up the last pieces of page fault accountings mm/xtensa: use general page fault accounting mm/x86: use general page fault accounting mm/sparc64: use general page fault accounting mm/sparc32: use general page fault accounting mm/sh: use general page fault accounting mm/s390: use general page fault accounting mm/riscv: use general page fault accounting mm/powerpc: use general page fault accounting mm/parisc: use general page fault accounting mm/openrisc: use general page fault accounting mm/nios2: use general page fault accounting mm/nds32: use general page fault accounting mm/mips: use general page fault accounting mm/microblaze: use general page fault accounting mm/m68k: use general page fault accounting mm/ia64: use general page fault accounting mm/hexagon: use general page fault accounting mm/csky: use general page fault accounting ...
This commit is contained in:
@@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
|
||||
Amount of memory used for storing in-kernel data
|
||||
structures.
|
||||
|
||||
percpu
|
||||
Amount of memory used for storing per-cpu kernel
|
||||
data structures.
|
||||
|
||||
sock
|
||||
Amount of memory used in network transmission buffers
|
||||
|
||||
|
@@ -164,7 +164,8 @@ core_pattern
|
||||
%s signal number
|
||||
%t UNIX time of dump
|
||||
%h hostname
|
||||
%e executable filename (may be shortened)
|
||||
%e executable filename (may be shortened, could be changed by prctl etc)
|
||||
%f executable filename
|
||||
%E executable path
|
||||
%c maximum size of core file by resource limit RLIMIT_CORE
|
||||
%<OTHER> both are dropped
|
||||
|
@@ -119,6 +119,21 @@ all zones are compacted such that free memory is available in contiguous
|
||||
blocks where possible. This can be important for example in the allocation of
|
||||
huge pages although processes will also directly compact memory as required.
|
||||
|
||||
compaction_proactiveness
|
||||
========================
|
||||
|
||||
This tunable takes a value in the range [0, 100] with a default value of
|
||||
20. This tunable determines how aggressively compaction is done in the
|
||||
background. Setting it to 0 disables proactive compaction.
|
||||
|
||||
Note that compaction has a non-trivial system-wide impact as pages
|
||||
belonging to different processes are moved around, which could also lead
|
||||
to latency spikes in unsuspecting applications. The kernel employs
|
||||
various heuristics to avoid wasting CPU cycles if it detects that
|
||||
proactive compaction is not being effective.
|
||||
|
||||
Be careful when setting it to extreme values like 100, as that may
|
||||
cause excessive background compaction activity.
|
||||
|
||||
compact_unevictable_allowed
|
||||
===========================
|
||||
|
@@ -1633,9 +1633,6 @@ may allocate from based on an estimation of its current memory and swap use.
|
||||
For example, if a task is using all allowed memory, its badness score will be
|
||||
1000. If it is using half of its allowed memory, its score will be 500.
|
||||
|
||||
There is an additional factor included in the badness score: the current memory
|
||||
and swap usage is discounted by 3% for root processes.
|
||||
|
||||
The amount of "allowed" memory depends on the context in which the oom killer
|
||||
was called. If it is due to the memory assigned to the allocating task's cpuset
|
||||
being exhausted, the allowed memory represents the set of mems assigned to that
|
||||
@@ -1671,11 +1668,6 @@ The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
|
||||
value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
|
||||
requires CAP_SYS_RESOURCE.
|
||||
|
||||
Caveat: when a parent task is selected, the oom killer will sacrifice any first
|
||||
generation children with separate address spaces instead, if possible. This
|
||||
avoids servers and important system daemons from being killed and loses the
|
||||
minimal amount of work.
|
||||
|
||||
|
||||
3.2 /proc/<pid>/oom_score - Display current oom-killer score
|
||||
-------------------------------------------------------------
|
||||
@@ -1684,6 +1676,9 @@ This file can be used to check the current score used by the oom-killer for
|
||||
any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which
|
||||
process should be killed in an out-of-memory situation.
|
||||
|
||||
Please note that the exported value includes oom_score_adj so it is
|
||||
effectively in range [0,2000].
|
||||
|
||||
|
||||
3.3 /proc/<pid>/io - Display the IO accounting fields
|
||||
-------------------------------------------------------
|
||||
|
@@ -253,5 +253,32 @@ which are function pointers of struct address_space_operations.
|
||||
PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag
|
||||
for own purpose.
|
||||
|
||||
Monitoring Migration
|
||||
=====================
|
||||
|
||||
The following events (counters) can be used to monitor page migration.
|
||||
|
||||
1. PGMIGRATE_SUCCESS: Normal page migration success. Each count means that a
|
||||
page was migrated. If the page was a non-THP page, then this counter is
|
||||
increased by one. If the page was a THP, then this counter is increased by
|
||||
the number of THP subpages. For example, migration of a single 2MB THP that
|
||||
has 4KB-size base pages (subpages) will cause this counter to increase by
|
||||
512.
|
||||
|
||||
2. PGMIGRATE_FAIL: Normal page migration failure. Same counting rules as for
|
||||
_SUCCESS, above: this will be increased by the number of subpages, if it was
|
||||
a THP.
|
||||
|
||||
3. THP_MIGRATION_SUCCESS: A THP was migrated without being split.
|
||||
|
||||
4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split.
|
||||
|
||||
5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had
|
||||
to be split. After splitting, a migration retry was used for it's sub-pages.
|
||||
|
||||
THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or
|
||||
PGMIGRATE_FAIL events. For example, a THP migration failure will cause both
|
||||
THP_MIGRATION_FAIL and PGMIGRATE_FAIL to increase.
|
||||
|
||||
Christoph Lameter, May 8, 2006.
|
||||
Minchan Kim, Mar 28, 2016.
|
||||
|
Reference in New Issue
Block a user