As is explained by Michal Hocko:
: Looking at the history, this has been added by 82f71ae4a2b8
: ("mm: catch memory commitment underflow") to have a safety check
: for issues which have been fixed. There doesn't seem to be any bug
: reports mentioning this splat since then so it is likely just
: spending cycles for a hot path (yes many people run with DEBUG_VM)
: without a strong reason.
Signed-off-by: Feng Tang <feng.t...@intel.com>
Cc: Konstantin Khlebnikov <koc...@gmail.com>
Cc: Qian Cai <c...@lca.pw>
Cc: Michal Hocko <mho...@suse.com>
Cc: Andi Kleen <andi.kl...@intel.com>
---
mm/util.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index 3c7a08c..fe63271 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -814,14 +814,6 @@ int __vm_enough_memory(struct mm_struct *mm, long pages,
int cap_sys_admin)
{
long allowed;
- /*
- * A transient decrease in the value is unlikely, so no need
- * READ_ONCE() for vm_committed_as.count.
- */
- VM_WARN_ONCE(data_race(percpu_counter_read(&vm_committed_as) <
- -(s64)vm_committed_as_batch * num_online_cpus()),
- "memory commitment underflow");
-
vm_acct_memory(pages);
/*
--
2.7.4
