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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 EA524C433E1 for ; Sun, 5 Jul 2020 12:59:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BAF03206B6 for ; Sun, 5 Jul 2020 12:59:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAF03206B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2F48D8D002E; Sun, 5 Jul 2020 08:59:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A5588D0001; Sun, 5 Jul 2020 08:59:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 194C68D002E; Sun, 5 Jul 2020 08:59:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id 0384F8D0001 for ; Sun, 5 Jul 2020 08:59:02 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 83108181AC9CB for ; Sun, 5 Jul 2020 12:59:02 +0000 (UTC) X-FDA: 77004027324.23.sheep17_040a5f926ea3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 4C73237606 for ; Sun, 5 Jul 2020 12:59:02 +0000 (UTC) X-HE-Tag: sheep17_040a5f926ea3 X-Filterd-Recvd-Size: 3307 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Sun, 5 Jul 2020 12:59:00 +0000 (UTC) IronPort-SDR: rt9qAaQATBxMJJD1b+d6I+wjW0CzBPgGHs1XIe6rp9ue43lZGlcFBcO2v5jOEywSEkJX3z0E9Q CYH6gXAU9hKQ== X-IronPort-AV: E=McAfee;i="6000,8403,9672"; a="134764661" X-IronPort-AV: E=Sophos;i="5.75,316,1589266800"; d="scan'208";a="134764661" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2020 05:58:59 -0700 IronPort-SDR: OeUWEir2wMUVDpL1KgIbZoJz3NKkIave0HxqjfxLXRQ0+GCxHjhVAdNJEqhDR/DfvM3UFqk4Ik mhzsftua3R1w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,316,1589266800"; d="scan'208";a="456398582" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.146.107]) by orsmga005.jf.intel.com with ESMTP; 05 Jul 2020 05:58:55 -0700 Date: Sun, 5 Jul 2020 20:58:54 +0800 From: Feng Tang To: Qian Cai Cc: kernel test robot , Andrew Morton , Michal Hocko , Johannes Weiner , Matthew Wilcox , Mel Gorman , Kees Cook , Luis Chamberlain , Iurii Zaikin , 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 Message-ID: <20200705125854.GA66252@shbuild999.sh.intel.com> References: <20200705044454.GA90533@shbuild999.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Queue-Id: 4C73237606 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: On Sun, Jul 05, 2020 at 08:15:03AM -0400, Qian Cai wrote: > > > > On Jul 5, 2020, at 12:45 AM, Feng Tang 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