linux.git/mm/vmstat.c, branch v4.19

mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly

2018-10-05T23:32:05+00:00

5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even
on UP") made the availability of the NR_TLB_REMOTE_FLUSH* counters inside
the kernel unconditional to reduce #ifdef soup, but (either to avoid
showing dummy zero counters to userspace, or because that code was missed)
didn't update the vmstat_array, meaning that all following counters would
be shown with incorrect values.

This only affects kernel builds with
CONFIG_VM_EVENT_COUNTERS=y && CONFIG_DEBUG_TLBFLUSH=y && CONFIG_SMP=n.

Link: http://lkml.kernel.org/r/20181001143138.95119-2-jannh@google.com
Fixes: 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP")
Signed-off-by: Jann Horn 
Reviewed-by: Kees Cook 
Reviewed-by: Andrew Morton 
Acked-by: Michal Hocko 
Acked-by: Roman Gushchin 
Cc: Davidlohr Bueso 
Cc: Oleg Nesterov 
Cc: Christoph Lameter 
Cc: Kemi Wang 
Cc: Andy Lutomirski 
Cc: Ingo Molnar 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

mm/vmstat.c: fix outdated vmstat_text

2018-10-05T23:32:05+00:00

7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely") removed the
VMACACHE_FULL_FLUSHES statistics, but didn't remove the corresponding
entry in vmstat_text.  This causes an out-of-bounds access in
vmstat_show().

Luckily this only affects kernels with CONFIG_DEBUG_VM_VMACACHE=y, which
is probably very rare.

Link: http://lkml.kernel.org/r/20181001143138.95119-1-jannh@google.com
Fixes: 7a9cdebdcc17 ("mm: get rid of vmacache_flush_all() entirely")
Signed-off-by: Jann Horn 
Reviewed-by: Kees Cook 
Reviewed-by: Andrew Morton 
Acked-by: Michal Hocko 
Acked-by: Roman Gushchin 
Cc: Davidlohr Bueso 
Cc: Oleg Nesterov 
Cc: Christoph Lameter 
Cc: Kemi Wang 
Cc: Andy Lutomirski 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Revert mm/vmstat.c: fix vmstat_update() preemption BUG

2018-06-28T18:16:44+00:00

Revert commit c7f26ccfb2c3 ("mm/vmstat.c: fix vmstat_update() preemption
BUG").  Steven saw a "using smp_processor_id() in preemptible" message
and added a preempt_disable() section around it to keep it quiet.  This
is not the right thing to do it does not fix the real problem.

vmstat_update() is invoked by a kworker on a specific CPU.  This worker
it bound to this CPU.  The name of the worker was "kworker/1:1" so it
should have been a worker which was bound to CPU1.  A worker which can
run on any CPU would have a `u' before the first digit.

smp_processor_id() can be used in a preempt-enabled region as long as
the task is bound to a single CPU which is the case here.  If it could
run on an arbitrary CPU then this is the problem we have an should seek
to resolve.

Not only this smp_processor_id() must not be migrated to another CPU but
also refresh_cpu_vm_stats() which might access wrong per-CPU variables.
Not to mention that other code relies on the fact that such a worker
runs on one specific CPU only.

Therefore revert that commit and we should look instead what broke the
affinity mask of the kworker.

Link: http://lkml.kernel.org/r/20180504104451.20278-1-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior 
Cc: Steven J. Hill 
Cc: Tejun Heo 
Cc: Vlastimil Babka 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: introduce proc_create_seq{,_data}

2018-05-16T05:23:35+00:00

Variants of proc_create{,_data} that directly take a struct seq_operations
argument and drastically reduces the boilerplate code in the callers.

All trivial callers converted over.

Signed-off-by: Christoph Hellwig

mm: don't show nr_indirectly_reclaimable in /proc/vmstat

2018-05-12T00:28:45+00:00

Don't show nr_indirectly_reclaimable in /proc/vmstat, because there is
no need to export this vm counter to userspace, and some changes are
expected in reclaimable object accounting, which can alter this counter.

Link: http://lkml.kernel.org/r/20180425191422.9159-1-guro@fb.com
Signed-off-by: Roman Gushchin 
Acked-by: Vlastimil Babka 
Reviewed-by: Andrew Morton 
Cc: Matthew Wilcox 
Cc: Alexander Viro 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES

2018-04-11T17:28:29+00:00

Patch series "indirectly reclaimable memory", v2.

This patchset introduces the concept of indirectly reclaimable memory
and applies it to fix the issue of when a big number of dentries with
external names can significantly affect the MemAvailable value.

This patch (of 3):

Introduce a concept of indirectly reclaimable memory and adds the
corresponding memory counter and /proc/vmstat item.

Indirectly reclaimable memory is any sort of memory, used by the kernel
(except of reclaimable slabs), which is actually reclaimable, i.e.  will
be released under memory pressure.

The counter is in bytes, as it's not always possible to count such
objects in pages.  The name contains BYTES by analogy to
NR_KERNEL_STACK_KB.

Link: http://lkml.kernel.org/r/20180305133743.12746-2-guro@fb.com
Signed-off-by: Roman Gushchin 
Reviewed-by: Andrew Morton 
Cc: Alexander Viro 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/vmstat.c: fix vmstat_update() preemption BUG

2018-03-28T23:42:05+00:00

Attempting to hotplug CPUs with CONFIG_VM_EVENT_COUNTERS enabled can
cause vmstat_update() to report a BUG due to preemption not being
disabled around smp_processor_id().

Discovered on Ubiquiti EdgeRouter Pro with Cavium Octeon II processor.

  BUG: using smp_processor_id() in preemptible [00000000] code:
  kworker/1:1/269
  caller is vmstat_update+0x50/0xa0
  CPU: 0 PID: 269 Comm: kworker/1:1 Not tainted
  4.16.0-rc4-Cavium-Octeon-00009-gf83bbd5-dirty #1
  Workqueue: mm_percpu_wq vmstat_update
  Call Trace:
    show_stack+0x94/0x128
    dump_stack+0xa4/0xe0
    check_preemption_disabled+0x118/0x120
    vmstat_update+0x50/0xa0
    process_one_work+0x144/0x348
    worker_thread+0x150/0x4b8
    kthread+0x110/0x140
    ret_from_kernel_thread+0x14/0x1c

Link: http://lkml.kernel.org/r/1520881552-25659-1-git-send-email-steven.hill@cavium.com
Signed-off-by: Steven J. Hill 
Reviewed-by: Andrew Morton 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm, sysctl: make NUMA stats configurable

2017-11-16T02:21:07+00:00

This is the second step which introduces a tunable interface that allow
numa stats configurable for optimizing zone_statistics(), as suggested
by Dave Hansen and Ying Huang.

=========================================================================

When page allocation performance becomes a bottleneck and you can
tolerate some possible tool breakage and decreased numa counter
precision, you can do:

	echo 0 > /proc/sys/vm/numa_stat

In this case, numa counter update is ignored.  We can see about
*4.8%*(185->176) drop of cpu cycles per single page allocation and
reclaim on Jesper's page_bench01 (single thread) and *8.1%*(343->315)
drop of cpu cycles per single page allocation and reclaim on Jesper's
page_bench03 (88 threads) running on a 2-Socket Broadwell-based server
(88 threads, 126G memory).

Benchmark link provided by Jesper D Brouer (increase loop times to
10000000):

  https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/bench

=========================================================================

When page allocation performance is not a bottleneck and you want all
tooling to work, you can do:

	echo 1 > /proc/sys/vm/numa_stat

This is system default setting.

Many thanks to Michal Hocko, Dave Hansen, Ying Huang and Vlastimil Babka
for comments to help improve the original patch.

[keescook@chromium.org: make sure mutex is a global static]
  Link: http://lkml.kernel.org/r/20171107213809.GA4314@beast
Link: http://lkml.kernel.org/r/1508290927-8518-1-git-send-email-kemi.wang@intel.com
Signed-off-by: Kemi Wang 
Signed-off-by: Kees Cook 
Reported-by: Jesper Dangaard Brouer 
Suggested-by: Dave Hansen 
Suggested-by: Ying Huang 
Acked-by: Vlastimil Babka 
Acked-by: Michal Hocko 
Cc: "Luis R . Rodriguez" 
Cc: Kees Cook 
Cc: Jonathan Corbet 
Cc: Mel Gorman 
Cc: Johannes Weiner 
Cc: Christopher Lameter 
Cc: Sebastian Andrzej Siewior 
Cc: Andrey Ryabinin 
Cc: Tim Chen 
Cc: Andi Kleen 
Cc: Aaron Lu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: remove unused pgdat->inactive_ratio

2017-11-16T02:21:03+00:00

Since commit 59dc76b0d4df ("mm: vmscan: reduce size of inactive file
list") 'pgdat->inactive_ratio' is not used, except for printing
"node_inactive_ratio: 0" in /proc/zoneinfo output.

Remove it.

Link: http://lkml.kernel.org/r/20171003152611.27483-1-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin 
Reviewed-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: consider the number in local CPUs when reading NUMA stats

2017-09-09T01:26:47+00:00

To avoid deviation, the per cpu number of NUMA stats in
vm_numa_stat_diff[] is included when a user *reads* the NUMA stats.

Since NUMA stats does not be read by users frequently, and kernel does not
need it to make a decision, it will not be a problem to make the readers
more expensive.

Link: http://lkml.kernel.org/r/1503568801-21305-4-git-send-email-kemi.wang@intel.com
Signed-off-by: Kemi Wang 
Reported-by: Jesper Dangaard Brouer 
Acked-by: Mel Gorman 
Cc: Aaron Lu 
Cc: Andi Kleen 
Cc: Christopher Lameter 
Cc: Dave Hansen 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Tim Chen 
Cc: Ying Huang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds