From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: [patch 008/127] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check Date: Thu, 04 Jun 2020 16:46:11 -0700 Message-ID: <20200604234611.U9pz2usYX%akpm@linux-foundation.org> References: <20200604164523.e15f3177f4b69dcb4f2534a1@linux-foundation.org> Reply-To: linux-kernel@vger.kernel.org Return-path: Received: from mail.kernel.org ([198.145.29.99]:41210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgFDXqN (ORCPT ); Thu, 4 Jun 2020 19:46:13 -0400 In-Reply-To: <20200604164523.e15f3177f4b69dcb4f2534a1@linux-foundation.org> Sender: mm-commits-owner@vger.kernel.org List-Id: mm-commits@vger.kernel.org To: akpm@linux-foundation.org, andi.kleen@intel.com, cai@lca.pw, feng.tang@intel.com, hannes@cmpxchg.org, keescook@chromium.org, koct9i@gmail.com, linux-mm@kvack.org, mgorman@suse.de, mhocko@suse.com, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, willy@infradead.org From: Feng Tang Subject: mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check This check was added by 82f71ae4a2b8 ("mm: catch memory commitment underflow") in 2014 to have a safety check for issues which have been fixed. And there has been few report caught by it, as described in its commit log: : This shouldn't happen any more - the previous two patches fixed : the committed_as underflow issues. But it was really found by Qian Cai when he used the LTP memory stress suite to test a RFC patchset, which tries to improve scalability of per-cpu counter 'vm_committed_as', by chosing a bigger 'batch' number for loose overcommit policies (OVERCOMMIT_ALWAYS and OVERCOMMIT_GUESS), while keeping current number for OVERCOMMIT_NEVER. With that patchset, when system firstly uses a loose policy, the 'vm_committed_as' count could be a big negative value, as its big 'batch' number allows a big deviation, then when the policy is changed to OVERCOMMIT_NEVER, the 'batch' will be decreased to a much smaller value, thus hits this WARN check. To mitigate this, one proposed solution is to queue work on all online CPUs to do a local sync for 'vm_committed_as' when changing policy to OVERCOMMIT_NEVER, plus some global syncing to garante the case won't be hit. But this solution is costy and slow, given this check hasn't shown real trouble or benefit, simply drop it from one hot path of MM. And perf stats does show some tiny saving for removing it. Link: http://lkml.kernel.org/r/20200603094804.GB89848@shbuild999.sh.intel.com Signed-off-by: Feng Tang Reported-by: Qian Cai Reviewed-by: Qian Cai Acked-by: Michal Hocko Cc: Konstantin Khlebnikov Cc: Andi Kleen Cc: Johannes Weiner Cc: Matthew Wilcox Cc: Mel Gorman Cc: Kees Cook Signed-off-by: Andrew Morton --- mm/util.c | 4 ---- 1 file changed, 4 deletions(-) --- a/mm/util.c~mm-utilc-remove-the-vm_warn_once-for-vm_committed_as-underflow-check +++ a/mm/util.c @@ -796,10 +796,6 @@ int __vm_enough_memory(struct mm_struct { long allowed; - VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) < - -(s64)vm_committed_as_batch * num_online_cpus(), - "memory commitment underflow"); From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC87CC433E0 for ; Thu, 4 Jun 2020 23:46:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 86CFC20659 for ; Thu, 4 Jun 2020 23:46:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="td4i58Sk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 86CFC20659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 32884280008; Thu, 4 Jun 2020 19:46:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D9DA280002; Thu, 4 Jun 2020 19:46:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A20E280008; Thu, 4 Jun 2020 19:46:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 031B1280002 for ; Thu, 4 Jun 2020 19:46:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B59803751 for ; Thu, 4 Jun 2020 23:46:13 +0000 (UTC) X-FDA: 76893165426.26.glass22_361116826d9b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 967141804B670 for ; Thu, 4 Jun 2020 23:46:13 +0000 (UTC) X-HE-Tag: glass22_361116826d9b X-Filterd-Recvd-Size: 4017 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Jun 2020 23:46:13 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E647520825; Thu, 4 Jun 2020 23:46:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591314372; bh=3me9rxAgTH5r2CCPrCcYM+jBAmZJUrkeP2J0Bi6e6oQ=; h=Date:From:To:Subject:In-Reply-To:From; b=td4i58SkX3TAJBlVbbKHBNrZyDHXlv9uvRVQuIoXqrLPSH0JgRDSGi9YU3CT/wH6u XoRJSRX5KmN7/SJnG2nA5VrtrC5bZqO9e8IzuowGmVBfJwRaKQ+fnPPKliGfIBP5c4 eiyrlaoz2gyfGxJrwEO/HyY0L6H1WUdYRrXMV2is= Date: Thu, 04 Jun 2020 16:46:11 -0700 From: Andrew Morton To: akpm@linux-foundation.org, andi.kleen@intel.com, cai@lca.pw, feng.tang@intel.com, hannes@cmpxchg.org, keescook@chromium.org, koct9i@gmail.com, linux-mm@kvack.org, mgorman@suse.de, mhocko@suse.com, mm-commits@vger.kernel.org, torvalds@linux-foundation.org, willy@infradead.org Subject: [patch 008/127] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check Message-ID: <20200604234611.U9pz2usYX%akpm@linux-foundation.org> In-Reply-To: <20200604164523.e15f3177f4b69dcb4f2534a1@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Queue-Id: 967141804B670 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Feng Tang Subject: mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check This check was added by 82f71ae4a2b8 ("mm: catch memory commitment underflow") in 2014 to have a safety check for issues which have been fixed. And there has been few report caught by it, as described in its commit log: : This shouldn't happen any more - the previous two patches fixed : the committed_as underflow issues. But it was really found by Qian Cai when he used the LTP memory stress suite to test a RFC patchset, which tries to improve scalability of per-cpu counter 'vm_committed_as', by chosing a bigger 'batch' number for loose overcommit policies (OVERCOMMIT_ALWAYS and OVERCOMMIT_GUESS), while keeping current number for OVERCOMMIT_NEVER. With that patchset, when system firstly uses a loose policy, the 'vm_committed_as' count could be a big negative value, as its big 'batch' number allows a big deviation, then when the policy is changed to OVERCOMMIT_NEVER, the 'batch' will be decreased to a much smaller value, thus hits this WARN check. To mitigate this, one proposed solution is to queue work on all online CPUs to do a local sync for 'vm_committed_as' when changing policy to OVERCOMMIT_NEVER, plus some global syncing to garante the case won't be hit. But this solution is costy and slow, given this check hasn't shown real trouble or benefit, simply drop it from one hot path of MM. And perf stats does show some tiny saving for removing it. Link: http://lkml.kernel.org/r/20200603094804.GB89848@shbuild999.sh.intel.com Signed-off-by: Feng Tang Reported-by: Qian Cai Reviewed-by: Qian Cai Acked-by: Michal Hocko Cc: Konstantin Khlebnikov Cc: Andi Kleen Cc: Johannes Weiner Cc: Matthew Wilcox Cc: Mel Gorman Cc: Kees Cook Signed-off-by: Andrew Morton --- mm/util.c | 4 ---- 1 file changed, 4 deletions(-) --- a/mm/util.c~mm-utilc-remove-the-vm_warn_once-for-vm_committed_as-underflow-check +++ a/mm/util.c @@ -796,10 +796,6 @@ int __vm_enough_memory(struct mm_struct { long allowed; - VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) < - -(s64)vm_committed_as_batch * num_online_cpus(), - "memory commitment underflow"); - vm_acct_memory(pages); /* _