From: Feng Tang <feng.tang@intel.com>
To: Qian Cai <cai@lca.pw>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
Mel Gorman <mgorman@suse.de>, Kees Cook <keescook@chromium.org>,
andi.kleen@intel.com, tim.c.chen@intel.com,
dave.hansen@intel.com, ying.huang@intel.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Konstantin Khlebnikov <koct9i@gmail.com>
Subject: Re: [PATCH v4 3/4] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check
Date: Fri, 29 May 2020 13:37:13 +0800 [thread overview]
Message-ID: <20200529053713.GH93879@shbuild999.sh.intel.com> (raw)
In-Reply-To: <20200529024928.GA4566@lca.pw>
On Thu, May 28, 2020 at 10:49:28PM -0400, Qian Cai wrote:
> On Fri, May 29, 2020 at 09:06:09AM +0800, Feng Tang wrote:
> > 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.
>
> Hmm, it looks like the warning is still useful to catch issues in,
>
> https://lore.kernel.org/linux-mm/20140624201606.18273.44270.stgit@zurg
> https://lore.kernel.org/linux-mm/54BB9A32.7080703@oracle.com/
>
> After read the whole discussion in that thread, I actually disagree with
> Michal. In order to get ride of this existing warning, it is rather
> someone needs a strong reason that could prove the performance hit is
> noticeable with some data.
One problem with current check is percpu_counter_read(&vm_committed_as)
is not accurate, and percpu_counter_sum() is way too heavy.
Thanks,
Feng
next prev parent reply other threads:[~2020-05-29 5:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 1:06 [PATCH v4 0/4] make vm_committed_as_batch aware of vm overcommit policy Feng Tang
2020-05-29 1:06 ` [PATCH v4 1/4] proc/meminfo: avoid open coded reading of vm_committed_as Feng Tang
2020-05-29 1:06 ` [PATCH v4 2/4] mm/util.c: make vm_memory_committed() more accurate Feng Tang
2020-06-03 13:35 ` Michal Hocko
2020-06-03 14:28 ` Andi Kleen
2020-06-04 1:38 ` Feng Tang
2020-05-29 1:06 ` [PATCH v4 3/4] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check Feng Tang
2020-05-29 2:49 ` Qian Cai
2020-05-29 5:37 ` Feng Tang [this message]
2020-06-02 3:37 ` Feng Tang
2020-05-29 1:06 ` [PATCH v4 4/4] mm: adjust vm_committed_as_batch according to vm overcommit policy Feng Tang
2020-06-03 13:38 ` Michal Hocko
2020-06-02 4:02 [PATCH v4 3/4] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check Qian Cai
2020-06-03 9:48 ` Feng Tang
2020-06-03 11:51 ` Qian Cai
2020-06-03 13:36 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200529053713.GH93879@shbuild999.sh.intel.com \
--to=feng.tang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=cai@lca.pw \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=keescook@chromium.org \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=tim.c.chen@intel.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.