From: Feng Tang <feng.tang@intel.com>
To: Qian Cai <cai@lca.pw>
Cc: kernel test robot <rong.a.chen@intel.com>,
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>,
Luis Chamberlain <mcgrof@kernel.org>,
Iurii Zaikin <yzaikin@google.com>,
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, lkp@lists.01.org
Subject: Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail
Date: Sun, 5 Jul 2020 20:58:54 +0800 [thread overview]
Message-ID: <20200705125854.GA66252@shbuild999.sh.intel.com> (raw)
In-Reply-To: <FAAE2B23-2565-4F36-B278-018A5AD219EE@lca.pw>
On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote:
>
>
> > On Jul 5, 2020, at 12:45 AM, Feng Tang <feng.tang@intel.com> wrote:
> >
> > I did reproduce the problem, and from the debugging, this should
> > be the same root cause as lore.kernel.org/lkml/20200526181459.GD991@lca.pw/
> > that loosing the batch cause some accuracy problem, and the solution of
> > adding some sync is still needed, which is dicussed in
>
> Well, before taking any of those patches now to fix the regression, we will need some performance data first. If it turned out the original performance gain is no longer relevant anymore due to this regression fix on top, it is best to drop this patchset and restore that VM_WARN_ONCE, so you can retry later once you found a better way to optimize.
The fix of adding sync only happens when the memory policy is being
changed to OVERCOMMIT_NEVER, which is not a frequent operation in
normal cases.
For the performance improvment data both in commit log and 0day report
https://lore.kernel.org/lkml/20200622132548.GS5535@shao2-debian/
it is for the will-it-scale's mmap testcase, which will not runtime
change memory overcommit policy, so the data should be still valid
with this fix.
Thanks,
Feng
next prev parent reply other threads:[~2020-07-05 12:59 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-21 7:36 [PATCH v5 0/3] make vm_committed_as_batch aware of vm overcommit policy Feng Tang
2020-06-21 7:36 ` [PATCH v5 1/3] proc/meminfo: avoid open coded reading of vm_committed_as Feng Tang
2020-06-21 7:36 ` [PATCH v5 2/3] mm/util.c: make vm_memory_committed() more accurate Feng Tang
2020-06-21 7:36 ` [PATCH v5 3/3] mm: adjust vm_committed_as_batch according to vm overcommit policy Feng Tang
2020-06-22 13:25 ` [mm] 4e2c82a409: will-it-scale.per_process_ops 1894.6% improvement kernel test robot
2020-07-02 6:32 ` [mm] 4e2c82a409: ltp.overcommit_memory01.fail kernel test robot
2020-07-02 7:12 ` Feng Tang
2020-07-05 3:20 ` Qian Cai
2020-07-05 4:44 ` Feng Tang
2020-07-05 12:15 ` Qian Cai
2020-07-05 12:58 ` Feng Tang [this message]
[not found] ` <20200705155232.GA608@lca.pw>
2020-07-06 1:43 ` Feng Tang
[not found] ` <20200706023614.GA1231@lca.pw>
2020-07-06 13:24 ` Feng Tang
2020-07-06 13:34 ` Andi Kleen
2020-07-06 23:42 ` Andrew Morton
2020-07-07 2:38 ` Feng Tang
2020-07-07 4:00 ` Huang, Ying
2020-07-07 5:41 ` Feng Tang
2020-07-09 4:55 ` Feng Tang
2020-07-09 13:40 ` Qian Cai
2020-07-09 14:15 ` Feng Tang
2020-07-10 1:38 ` Feng Tang
2020-07-07 1:06 ` Dennis Zhou
2020-07-07 3:24 ` Feng Tang
2020-07-07 10:28 ` Michal Hocko
2020-06-24 9:45 ` [PATCH v5 0/3] make vm_committed_as_batch aware of vm overcommit policy Michal Hocko
[not found] <AF8CFC10-7655-4664-974D-3632793B0710@lca.pw>
2020-07-07 12:06 ` [mm] 4e2c82a409: ltp.overcommit_memory01.fail Michal Hocko
[not found] ` <20200707130436.GA992@lca.pw>
2020-07-07 13:56 ` 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=20200705125854.GA66252@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=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@lists.01.org \
--cc=mcgrof@kernel.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=rong.a.chen@intel.com \
--cc=tim.c.chen@intel.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yzaikin@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).