From: Qian Cai <cai@lca.pw>
To: Feng Tang <feng.tang@intel.com>
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 11:52:32 -0400 [thread overview]
Message-ID: <20200705155232.GA608@lca.pw> (raw)
In-Reply-To: <20200705125854.GA66252@shbuild999.sh.intel.com>
On Sun, Jul 05, 2020 at 08:58:54PM +0800, Feng Tang wrote:
> 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.
Well, I would expect people are perfectly reasonable to use
OVERCOMMIT_NEVER for some workloads making it more frequent operations.
The question is now if any of those regression fixes would now regress
performance of OVERCOMMIT_NEVER workloads or just in-par with the data
before the patchset?
Given now this patchset has had so much churn recently, I would think
"should be still valid" is not really the answer we are looking for.
>
> Thanks,
> Feng
>
>
next prev parent reply other threads:[~2020-07-05 15:52 UTC|newest]
Thread overview: 34+ 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-06-22 13:25 ` 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
2020-07-05 15:52 ` Qian Cai [this message]
2020-07-06 1:43 ` Feng Tang
2020-07-06 2:36 ` Qian Cai
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-10 3:26 ` Qian Cai
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
-- strict thread matches above, loose matches on Subject: below --
2020-07-07 11:43 [mm] 4e2c82a409: ltp.overcommit_memory01.fail Qian Cai
2020-07-07 12:06 ` Michal Hocko
2020-07-07 13:04 ` Qian Cai
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=20200705155232.GA608@lca.pw \
--to=cai@lca.pw \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=dave.hansen@intel.com \
--cc=feng.tang@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 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.