On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote: > > > > On Jul 5, 2020, at 12:45 AM, Feng Tang <feng.t...@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.gd...@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
